From capwap-admin@frascone.com Thu Sep 01 15:55:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAv9V-00062F-3f for capwap-archive@megatron.ietf.org; Thu, 01 Sep 2005 15:55:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26773 for ; Thu, 1 Sep 2005 15:55:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6869F2062E; Thu, 1 Sep 2005 15:55:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22D112041D; Thu, 1 Sep 2005 15:55:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B5B842041D for ; Thu, 1 Sep 2005 15:54:05 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 607D12034F for ; Thu, 1 Sep 2005 15:54:00 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j81JldKs033247; Thu, 1 Sep 2005 12:47:39 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509011947.j81JldKs033247@homebrew.trpz.com> To: "David Case (davecase)" Cc: "Bob O'Hara (boohara)" , capwap@frascone.com Subject: Re: [Capwap] Expanded discussion on regulatory certification In-Reply-To: Your message of "Thu, 01 Sep 2005 14:48:36 EDT." <2C7C3316358DC24C8A99DAAE1182E1D27C3A3A@xmb-rtp-212.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <33245.1125604058.1@trpz.com> Content-Transfer-Encoding: quoted-printable From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 01 Sep 2005 12:47:38 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable David, Thanks for the explaination. So it is Cisco and Cisco only that can determine whether a change keeps a Cisco AP in compliance and that it is the policy of Cisco to say that any change done by a 3rd party makes the AP non-compliant. Regardless of the change, right? It was modified, Cisco didn't do it, so it doesn't matter... non-compliant. If a 3rd party modifies the software of a Cisco AP it does so "at [its] own risk" and Cisco would probably void the warranty. I understand why Cisco would have such a policy. Other companies may have other policies though. And since this is about a technical feature in an protocol under consideration of the IETF I think one particular corporate policy is irrelevant. The mere fact that an image has been downloaded does not mean the AP is immediately non-compliant. Apparently it can be used in a way to trigger certain corporate action but so what? I'm sure you'll agree that just because someone can take a gun and shoot oneself in the foot does not, in and of itself, mean that guns must be forbidden. Similarly with image download. You and Bob say that it could be used in a way to get Cisco very upset. OK, fine. It can also be used in other ways: - discount AP vendor shares particulars of AP HW for AC vendor to port code to. Discount AP vendor is happy because that means more sales for his APs. AC vendor is happy because he'd rather not be in the low-margin business of building APs. - company with standalone, "fat APs" enters into relationship with = AC vendor to OEM an AC and turn its "fat APs" into "thin", managed-by-AC APs running code developed by AC vendor. Now company can offer customers a choice-- fat or (OEM'd) thin. = - use your imagination.... Image download is useful and valuable. It does not immediately void certifications of APs, as I've been saying all along, and I still think it has to be included in the resulting CAPWAP protocol. Happy hunting, Dan. On Thu, 01 Sep 2005 14:48:36 EDT you wrote > I am supposedly on PTO today but got my limit of geese this morning and = now I > have time to look at email. > = > If we are talking one of our AP's they may have several certifications a= nd or > DofC's. We are the responsible party and as the responsible party for c= ompli >ance it is us and not anyone else who can make the determination that the= prod >uct is still compliant. > = > If a third party modifies our software they do so at their own risk. Si= nce w >e sign the DofC or letters of verification, those letters cover only the = versi >ons we tested and models we deem to be similar, we cover no 3rd party mod= ifica >tions > = > I should point out any changes may impact other regulatory and not just = FCC. = > If the product should have NEBS approval or IEC 60601-1-2 approval where= the = >software rev is part of the approval, these changes could void these appr= ovals >. > = > Also there is little issue of product warranty which will be voided by = unaut >horized changes. > = > I gave a call t the FCC while driving home and they concur it is Cisco a= nd no >t any third party who can determine if the change still keeps the system = compl >iant if done so under out FCC approvals. > = > If a 3rd party wants to change it then under FCC rules they need to labe= l it = >as being modified and list themselves as the responsible party. = > = > Our manuals state that any unauthorized changes could put the user at ri= sk to > operate the device under FCC and other regulatory regimes. > = > David A. Case NCE, NCT > Cisco Systems Inc > Senior Regulatory Engineer > Corporate Compliance EMC Standards and Operations > Stonegate Corp Park > 4125 Highlander Parkway > Richfield OH 44286 > T 330-523-2139 > = > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Be= half = >Of Dan Harkins > Sent: Wednesday, August 31, 2005 1:43 AM > To: Bob O'Hara (boohara) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Expanded discussion on regulatory certification = > = > Bob, > = > There's an atheros driver too that has explicit txpower parameters pas= sed t >o a HAL routine to transmit a packet. Mucking with that parameter would m= ake i >t non-compliant with the regulations. = > = > Dan. > = > On Tue, 30 Aug 2005 22:40:32 PDT you wrote > > Dan, > > = > > If I understand the driver that you reference, it has a firmware = > >component th at is created by Cisco embedded within it (cribbed by = > >reverse engineering the Cisco driver and extracting the binary that is = > >downloaded to the microcoded pr ocessor on the card). It is this = > >portion of the driver that controls any port ion of the radio that can = > >affect compliance with regulations. The portion of the driver that is = > >not developed by Cisco does not have access to the portions of the = > >802.11 card that can change its operation in a way that would make it n= on-co >mpliant with the regulations. > > = > > I am actually leaning in the direction that this an(4) driver would = > >not cause the FCC to fine anyone that might use it, because it = > >encompasses the Cisco mi crocode and might not be seen by the FCC as an= = > >unauthorized modification. The FCC might disagree with me, though, = > >and might require convincing to see thing s in this light. > > = > > I can also see an entirely reasonable interpretation of the = > >regulations that would say this is an unauthorized modification. > > = > > -Bob > > = > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com] > > Sent: Tuesday, August 30, 2005 8:13 PM > > To: Bob O'Hara (boohara) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Expanded discussion on regulatory certification > > = > > Bob, > > = > > I'll get back to you on the additional regulatory citations you've > > added-- they are numerous and require some reading and analysis-- but = > > I have an additional couple questions for you. > > = > > After I loaded freebsd on my laptop I got a driver to control a = > > Cisco Aironet card. It was not written by a Cisco employee. I can = > > modify this driver to my heart's content and continue to use my = > > modified driver to control that card. > > = > > Is it your contention that a Cisco Aironet card plugged into my = > > laptop loses its FCC certification? If so, is it also your contention = > that the FCC will fine anyone who plugs a Cisco Aironet card into a = > > computer running freebsd with the an(4) driver? > > = > > Dan. > > = > > On Tue, 30 Aug 2005 13:54:40 PDT you wrote > > > Dan, > > > = > > > Your example of loading a different OS onto a PC (which is an = > > > unintentional > > r > > >adiator in FCC terms) has little to do with the issue of loading code= = > > >that h > >as > > > control of radio parameters, such as transmit power, frequency of = > > > operation > >, > > >and spectral shape of the transmitted waveform, onto an AP/WTP (which= = > > >the FC > >C > > >classes as an intentional radiator). The OS or other programs = > > >running on a > >PC > > > will have little influence over the RF emissions of that device. = > > > Sure, cer > >ta > > >in code loops can be created to sing a song on a nearby radio. But, = > > >this is > > s > > >till within the requirements under which the PC was originally = > > >certified. D > >ow > > >nloading code to an AP/WTP that, for example, increases the power = > > >output on > >a > > >channel adjacent to the edge of a band, can cause the device to emit = > > >a signa > >l > > >that is above that allowed by its certification, causing illegal = > > >interferenc > >e > > >in the adjacent band. > > > = > > > The difference is very important. It is also very important that = > > > this disc > >us > > >sion continue in this forum, as there are very few, if any IETF = > > >documents th > >at > > > directly affect whether a device is legal to operate under = > > > governmental emi > >ss > > >ions regulations. This might be the first time that the IETF has had= = > > >to con > >si > > >der this issue. I believe that many here do not yet understand the = > > >importan > >ce > > > of the issue. > > > = > > > But, back to our discussion. > > > = > > > You say that it is possible to download code to an AP/WTP that = > > > "would retai > >n > > >its certification". This is where there is a fundamental point on = > > >which we > >di > > >sagree. I do agree with you that it is possible to download code = > > >from a thi > >rd > > > party onto an AP that would continue to have the AP operate in a = > > > compliant > >ma > > >nner. But, this is entirely different from that same AP with the = > > >third part > >y > > >code running on it maintaining its certification. > > > = > > > The certification "belongs" to the manufacturer of the device that = > > > obtained > > i > > >t. It is not transferable or modifiable by anyone else, without = > > >express aut > >ho > > >rization of the manufacturer. Downloading code that causes access to= = > > >the re > >gi > > >sters of a chip, for example, that has control of the RF transmission= = > > >charac > >te > > >ristics of the certified device is modifying the device. > > > = > > > Here are additional citations from the regulations governing the = > > > certificat > >io > > >n of radio frequency equipment in the United States, supporting this = > > >positio > >n. > > > = > > > 47CFR2.909 states the following: > > > = > > > The following parties are responsible for the compliance of radio = > > > frequency > > e > > >quipment with the applicable standards: > > > (a) In the case of equipment which requires the issuance by the = > > >Commission > >of > > > a grant of equipment authorization, the party to whom that grant of = > > > authori > >za > > >tion is issued (the grantee) If the radio frequency equipment is = > > >modified by > > a > > >ny party other than the grantee and that party is not working under = > > >the auth > >or > > >ization of the grantee pursuant to =A7 2.929(b), the party performing= = > > >the modif > >ic > > >ation is responsible for compliance of the product with the = > > >applicable admin > >is > > >trative and technical provisions in this chapter. > > > = > > > 47CFR2.909 (d) states the following: > > > (d) If, because of modifications performed subsequent to = > > > authorization, a n > >ew > > > party becomes responsible for ensuring that a product complies with = > > > the tec > >hn > > >ical standards and the new party does not obtain a new equipment = > > >authorizati > >on > > >, the equipment shall be labelled, following the specifications in =A7= = > > >2.925(d) > >, > > >with the following: ''This product has been modified by [insert name,= = > > >addres > >s > > >and telephone number of the party performing the modifications].'' > > > = > > > 47CFR2.929 states this, as well: > > > =A7 2.929 Nonassignability of an equipment authorization. > > > (a) An equipment authorization issued by the Commission may not be = > > > assigned > >, > > >exchanged or in any other way transferred to a second party. > > > = > > > So, for the example well below in this thread, either the third = > > > party WTP c > >od > > >e developer, the AC vendor that performs the unauthorized (by the = > > >original e > >qu > > >ipment manufacturer) download to the WTP, or possibly the customer = > > >that ente > >re > > >d the command to perform the download is now the party responsible = > > >for the c > >er > > >tification/authorization of the WTP, not the original manufacturer. = = > > >At a m > >in > > >imum, 47CFR2.909 (d) will require someone to physically access each = > > >modified > > W > > >TP to affix a sticker. Even without actually certifying the modified= = > > >WTP, t > >he > > > device is now the responsibility of someone other than the original = > > > manufac > >tu > > >rer to ensure that it meets the regulatory requirements. > > > = > > > Because our discussion touched on the possibility that the radio = > > > portion of > > a > > > modified WTP might be "identical" or use "identical code" to that = > > > used by t > >he > > > original manufacturer of the WTP, the following definition is = > > > provided by t > >he > > > FCC 47CFR2.908: > > > = > > > 2.908 Identical defined. > > > As used in this subpart, the term identical means identical within = > > > the vari > >at > > >ion that can be expected to arise as a result of quantity production = > > >techniq > >ue > > >s. > > > = > > > This definition does not encompass a third party changing the code = > > > operatin > >g > > >the device. > > > = > > > I would be very interested to understand how these regulatory = > > > requirements > >ca > > >n be integrated with your positions, below. > > > = > > > -Bob > > > = > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Wednesday, August 24, 2005 11:00 AM > > > To: Bob O'Hara (boohara) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Expanded discussion on regulatory = > > > certification > > > = > > > Bob, > > > = > > > You're absolutely right. Diversion to ad hominem attacks would not= = > > > serve the needs of this group. And it's great that no one has = > > > resorted to ad hominem attacks! > > > = > > > In your company A-D example you have moved the goal posts. Before = > > > you had stated that merely running someone else's code on an AP = > > > required recertification. Now you're asking whether an AP can remain= = > > > certified "regardless of what code [company B] might download to = > > > [Company D's] WTP". Well that's a different question altogether. > > > = > > > I believe it would be possible to download an image onto an AP = > > > that could make it uncompliant (it could, for example, make the AP = > > > broadcast outside legal limits) and it wouldn't matter whether the = > > > company that created the downloaded image is the same as the company= = > > > that certified the AP in the same place. I also believe that it is = > > > possible for a company to download an image onto another company's = > > AP and that AP would retain it's certification. > > > = > > > So to answer your quesiton, that depends on what kind of image = > > > Cisco downloaded on a Trapeze AP. You could do it right or you could= = > > > do it wrong. But the act of downloading the image does not void the = > > > certification of the AP as you have been asserting here all along. > > > = > > > My laptop is FCC certified. I don't know how it got certified. I = > > > do know that it was running Windows XP when I pulled it out of the b= ox. > > > I hate Windows XP and immediately installled FreeBSD on it. I don't = > > > believe my laptop is now in violation of FCC regulations nor do I = > > > feel it is necessary to get a different sticker on the bottom of my = > > > laptop. I am also unaware of the FCC going after anyone who has = > > > installed an operating system on a computer that was different than = > > > one it was shipped with. > > > = > > > You have been unable to demonstrate how image download voids an = > > > AP's certification and the snippets of FCC regulations you supplied = > > > did not say anything on that subject. Similarly I have been unable = > > > to demonstrate that image download will not void an AP's certificati= on. > > > So to answer your last question, yes, we disagree. Unless you can = > > > come up with an FCC ruling that refers to the issue at hand and = > > > unambiguously states it voids an AP's certification then I think we = > > > should just let this thread die a well-deserved death right here. > > > = > > > Dan. > > > = > > > On Mon, 22 Aug 2005 16:15:28 PDT you wrote > > > > Dan, > > > > = > > > > Diversion to ad hominem attacks does not serve the needs of this = > > > > discussion or of this group. > > > > = > > > > If, as you say, there are APs out there today that have been = > > > > certified with code from the AP vendor that are now running code = > > > > from a third party (where the AP has not been recertified to run = > > > > with that code), I have to assume that you have personal knowledge= = > > > > of these implementations. If you would, please provide a list (or= = > > > > at least one > > > > example) that might be provided to the FCC as an example for them = > > > > to resolve the question directly. > > > > = > > > > As I said, the code from the ART program used to certify our APs = > > > > and the parameters under which those APs are certified are running= = > > > > in the shipping AP under our controller. I am not sure which part= = > > > > of that statement is unclear. The fact that this code is further = > > > > integrated into a larger program that performs a number of = > > > > functions that do not impact the radio or its RF characteristics = > > > > is irrelevant to the certification. Even if such a larger program= = > > > > were to modify the RF characteristics, it is possible, with = > > > > limitations, for the manufacturer of the AP to file a "permissive = > > > > change" with the FCC to maintain its certification. The only = > > > > reason we might be able to do this is because we are the manufactu= rer o >f the AP and have previously certified the AP. > > > > An arbitrary third party is not allowed this freedom. > > > > = > > > > Let me be clearer also about the example and question from my last= = > > > > email. > > > > = > > > > Let's say Company A is a developer of AP/WTP download modules. > > > > Company B is an AC vendor that has licensed a module from Company = > > > > A for download through SLAPP. > > > > Company C is the customer that has deployed the WLAN. > > > > Company D is the manufacturer of the AP/WTP that has certified the= = > > > > device running their own code. > > > > = > > > > Your answer to my question below indicates to me that, if Cisco = > > > > were Company B and Trapeze were Company D, you believe that the = > > > > Trapeze certification of the AP/WTP would stand, regardless of = > > > > what code Cisco might download to the Trapeze AP/WTP. Am I = > > > > correct in my interpretation of your answer? > > > > = > > > > If I am correct in interpreting your answer to the question, I = > > > > disagree with your answer. I would find it wildly unlikely that = > > > > Trapeze would stand up and claim that their AP/WTP hardware is = > > > > fully compliant with the regulations when that hardware is running= = > > > > any code but their own. I am almost certain (though I don't speak= = > > > > for the company on this) that Cisco would not agree that our AP = > > > > would always operate within the regulations when running any code = than = >that supplied by Cisco. > > > > = > > > > Perhaps you disagree? > > > > = > > > > -Bob > > > > = > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > Sent: Monday, August 22, 2005 1:59 PM > > > > To: Bob O'Hara (boohara) > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Expanded discussion on regulatory = > > > > certification > > > > = > > > > Bob, > > > > = > > > > There's nothing cute about it. You're spreading FUD-- Fear (the = > > > > FCC will fine me!), Uncertainty (they don't recertify but I think = > > > > we might have to), and Doubt (he was wearing his "technical adviso= r hat >" > > > > and that must mean something). In fact, it's the opposite of cute;= = > > > > it's a big, smelly, steaming pile o' FUD. > > > > = > > > > If this issue is, as you say, as real as the fines the FCC will = > > > > levy then there is no issue. This is being done today and the FCC = > > > > is not fining anyone. > > > > = > > > > I was not implying any slight of hand. The thing is, you market = > > > > code that did not operate the AP when it was certified and you do = > > > > not recertify when you install that code on the AP. And nor should= = > > > > you because, as I've been saying all along, it is not necessary to= = > > > > recertify an AP simply because code that was not part of the = > > > > original certification is downloaded onto it. > > > > = > > > > To answer your question, company D had to have certified their = > > > > WTP prior to marketing it (they could've ran = > > > > ART_V48_build_13_alpha to get their certification, for instance). = > > > > Since they are the company responsible for certification they = > > > > would supply information as may be requested concerning the = > > > > operation of the device to the Commission or its representatives. > > > > = > > > > Dan. > > > > = > > > > On Mon, 22 Aug 2005 11:53:35 PDT you wrote > > > > > Dan, > > > > > = > > > > > The issue is not, as you put it, "just an unfortunate bunch of F= UD". > > > > > That is a cute attempt at diverting people from the issue. But = > > > > > ultimately, it is futile. The folks in the CAPWAP group can = > > > > > research and address this issue now, or surely those that = > > > > > implement and deploy > > > > a > > > > > CAPWAP protocol in the future will have to address it in the fut= ure. = > = > > > > > = > > > > > The requirement for certification of RF devices is not going to = > > > > > go > > > > away. > > > > > Let me quote a few bits from the FCC regulations for unlicensed > > > > devices: > > > > > = > > > > > Section 15.15 General technical requirements. > > > > > (b) An intentional or unintentional radiator must be constructed= = > > > > > such that the adjustments of any control that is readily = > > > > > accessible by or intended to be accessible to the user will not = > > > > > cause operation of the device in violation of the regulations. > > > > > = > > > > > Section 15.29 Inspection by the Commission. > > > > > (c) The party responsible for the compliance of any device = > > > > > subject to this Part shall promptly furnish to the Commission or= = > > > > > its representatives such information as may be requested = > > > > > concerning the operation of the device, including a copy of any = > > > > > measurements made for obtaining an equipment authorization or = > > > > > demonstrating compliance with the regulations. > > > > > = > > > > > Section 15.201 Equipment authorization requirement. > > > > > (b) Except as otherwise exempted in paragraph (c) of this = > > > > > Section and > > > > in > > > > > Section 15.23 of this > > > > > Part, all intentional radiators operating under the provisions = > > > > > of this Part shall be certificated by the Commission pursuant to= = > > > > > the procedures in Subpart J of Part 2 of this Chapter prior to = > > > > > marketing. > > > > > = > > > > > Who would you say is "the party responsible for the compliance" = > > > > > of a device that has been downloaded with third party code to = > > > > > operate the radio in an AP under the SLAPP proposal? If, for = > > > > > example, Company A were to distribute code written by Company B = > > > > > to Company C to download using SLAPP onto a WTP from Company D, = > > > > > who is responsible for ensuring that the device is operating = > > > > > within the regulations? In this > > > > scenario, > > > > > who is responsible for furnishing to the Commission a copy of = > > > > > the measurements made for obtaining equipment authorization? > > > > > = > > > > > To address your other point, yes, we certify using the ART test > > > > program. > > > > > We also incorporate the identical parameters and code required = > > > > > to maintain that certification in our operational code for the A= Ps. > > > > There > > > > > is no sleight of hand here, as it appears you are implying. > > > > > = > > > > > The issue of certification when an unauthorized third party = > > > > > downloads code onto a device incorporating a radio is real, as = > > > > > will be the fines levied by the FCC upon that third party (or = > > > > > perhaps the third party's customer, or both) for operating an RF= = > > > > > emitting device (an > > > > "intentional > > > > > radiator" in FCC terms) without the proper certifications. > > > > > = > > > > > You can try telling everyone to "ignore the man behind the curta= in" > > > > and > > > > > believe that you are living in Oz. But, in actuality, you are > > > > dreaming. > > > > > = > > > > > -Bob > > > > > = > > > > > -----Original Message----- > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > Sent: Wednesday, August 17, 2005 4:24 PM > > > > > To: Bob O'Hara (boohara) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory = > > > > > certification > > > > > = > > > > > Bob, > > > > > = > > > > > After looking at an FCC test report for the certification of = > > > > > Airespace's AS1250 it appears that you got certification not by = > > > > > running your operational AP code but by running = > > > > > "ART_V48_build_13_alpha". So you received certification for your= = > > > > > APs by running code on them that is not your's and is not what a= = > > > > > customer runs on them. Your own operational image is loaded onto= = > > > > > these APs prior to shipping yet you do not recertify them with > > > > this > > > > > new code load. > > > > > = > > > > > So this entire issue about recertification being necessary is = > > > > > just > > > > an > > > > > unfortunate bunch of FUD. > > > > > = > > > > > Dan. > > > > > = > > > > > On Thu, 04 Aug 2005 02:07:39 PDT you wrote > > > > > > <802.11 Technical advisor to CAPWAP hat> Yes, it is my = > > > > > > assertion that recertification is necessary. Just > > > > > because > > > > > > you suggest it may not be true, does not make it less true. > > > > > > > > > > > > = > > > > > > And actually, having to put another sticker on an AP has = > > > > > > everything > > > > to > > > > > > do with CAPWAP. Using a protocol that requires such manual > > > > operations > > > > > > at every CAPWAP AP (and not even manual operations across the > > > > network, > > > > > > but manual operations at the top of a ladder with your head = > > > > > > poked > > > > into > > > > > > the hole made by moving the ceiling tile aside) hardly makes = > > > > > > for > > > > ease > > > > > of > > > > > > management or configuration consistency. It seems that a = > > > > > > protocol > > > > > that > > > > > > requires such manual operations does not meet Objective 5.1.2,= = > > > > > > configuration consistency, since the protocol cannot allow an = > > > > > > AC to determine if it is legal to operate a third party WTP = > > > > > > after a > > > > software > > > > > > download has taken place. In the US, at least, it is not = > > > > > > legal to operate a Part 15.247 device (say, all 802.11b/g APs)= = > > > > > > without the appropriate FCCID. I am certain this is true in = > > > > > > many other > > > > regulatory > > > > > > domains, as well. > > > > > > = > > > > > > = > > > > > > -Bob > > > > > > = > > > > > > -----Original Message----- > > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > > Sent: Wednesday, August 03, 2005 3:29 AM > > > > > > To: Bob O'Hara (boohara) > > > > > > Cc: capwap@frascone.com > > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > > > certification > > > > > > = > > > > > > I was that presenter and I don't think that recertification = > > > > > > is necessary, but again, that's outside my job function. > > > > > > = > > > > > > It may be your assertion that recertification is necessary = > > > > > > but > > > > > that's > > > > > > just your assertion, it doesn't mean it's true. And = > > > > > > furthermore > > > > > whether > > > > > > someone has to put a sticker on an AP has nothing to do with C= APWAP >. > > > > = > > > > > > = > > > > > > Dan. > > > > > > = > > > > > > On Wed, 03 Aug 2005 03:04:21 PDT you wrote > > > > > > > At the working group meeting, I asked the presenter for = > > > > > > SLAPP > > > > about > > > > > > the > > > > > > > impact of downloading code into third party WTPs that have > > > > received > > > > > > > regulatory certification. At that time, the presenter said = > > > > > > > that > > > > he > > > > > > was > > > > > > > not expert in that area, but suspected that recertification = > > > > > > > of the device would be necessary with the newly downloaded = > > > > > > > code. I would > > > > > > like > > > > > > > to discuss this further on the list. = > > > > > > > = > > > > > > > It is my assertion that all regulatory agencies that require= = > > > > > > > certification of WTPs for operation in their jurisdiction = > > > > > > > will > > > > > require > > > > > > > that WTPs that receive code and use it for operation, when = > > > > > > > that > > > > code > > > > > > is > > > > > > > not from the entity that received the original certification= = > > > > > > > for > > > > the > > > > > > > device, will require a new certification of that device with= = > > > > > > > the > > > > > new, > > > > > > > third party code. > > > > > > > = > > > > > > > In addition, nearly all regulatory agencies, certainly those= = > > > > > > > in > > > > > North > > > > > > > America, Europe, Asia, and the Middle East, require an = > > > > > > > external indication of the certification, usually a sticker = > > > > > > > with an > > > > > identifying > > > > > > > string. I also assert that downloading new code to a third = > > > > > > > party > > > > > WTP > > > > > > > will require that all WTPs that have received that code must= = > > > > > > > now > > > > > also > > > > > > be > > > > > > > physically accessed to have a new sticker affixed. > > > > > > > = > > > > > > > It is not sufficient for an AC vendor to simply develop code= = > > > > > > > ports > > > > > for > > > > > > > each silicon vendor and WTP reference design from those = > > > > > > > silicon > > > > > > vendors. > > > > > > > The AC vendors must now obtain regulatory certification for = > > > > > > > every > > > > > WTP > > > > > > > manufactured. Similarly, each WTP vendor must now obtain > > > > regulatory > > > > > > > certification with every AC vendor. > > > > > > > = > > > > > > > This will be a significant additional cost for all AC and = > > > > > > > WTP > > > > > vendors. > > > > > > > Where current devices need to be certified once for each > > > > regulatory > > > > > > > domain, SLAPP will require that each device is certified = > > > > > > > several > > > > > times > > > > > > > for each regulatory domain. The cost of regulatory = > > > > > > > certification > > > > > for > > > > > > an > > > > > > > AC vendor is now multiplied by the number of WTPs that is > > > > supports. > > > > > > > Similarly, the cost of certification for a WTP vendor is > > > > multiplied > > > > > by > > > > > > > the number of ACs that are supported. Even sharing the cost= = > > > > > > > of certification between AC and WTP vendor only cuts this = > > > > > > > cost in > > > > half. > > > > > > It > > > > > > > is still dramatically larger than with any other proposal. > > > > > > > = > > > > > > > This is a very important issue. With SLAPP, it is no longer > > > > > > sufficient > > > > > > > to state support for the ultimate CAPWAP protocol to be > > > > > interoperable. > > > > > > > It is now necessary that there be a specific business > > > > relationships > > > > > > > between AC and WTP vendors or a list of "compatible" vendors= = > > > > > > > and > > > > > model > > > > > > > numbers. > > > > > > > = > > > > > > > I believe that this also significantly raises the barriers = > > > > > > > to > > > > entry > > > > > > for > > > > > > > AC and WTP vendors, since the cost of market entry is = > > > > > > > associated > > > > > with > > > > > > > the costs of regulatory certification with a potentially = > > > > > > > large > > > > > number > > > > > > of > > > > > > > ACs and WTPs. As the number of ACs and WTPs increase, this = > > > > > > > cost > > > > > also > > > > > > > increases. The result is likely to be an entrenchment of = > > > > > > > the > > > > early > > > > > > > entrants into this market and the exclusion of new participa= nts. > > > > > > > = > > > > > > > So, my final assertion is that adoption of the SLAPP model = > > > > > > > for > > > > > CAPWAP > > > > > > > would have exactly the opposite effect that is desired from = > > > > > > > standardization, which is lower costs, greater competition, = > > > > > > > and > > > > > widely > > > > > > > interoperable products. > > > > > > > = > > > > > > > -Bob > > > > > > > = > > > > > > > Bob O'Hara > > > > > > > Cisco Systems - WNBU > > > > > > > = > > > > > > > Phone: +1 408 853 5513 > > > > > > > Mobile: +1 408 218 4025 > > > > > > > = > > > > > > > _______________________________________________ > > > > > > > Capwap mailing list > > > > > > > Capwap@frascone.com > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > = > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > = > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > = > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > = > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > = > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > = > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > = _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From echte@doneasy.com Thu Sep 01 20:45:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzgV-000123-HC; Thu, 01 Sep 2005 20:45:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09532; Thu, 1 Sep 2005 20:45:32 -0400 (EDT) Received: from 91.red-80-34-53.pooles.rima-tde.net ([80.34.53.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EAziW-0002iG-Ul; Thu, 01 Sep 2005 20:47:43 -0400 Received: from wuhj8L ([10.40.5.9]) by 132.151.6.1 with Microsoft SMTPSVC(6.0.3790.002); Thu, 01 Sep 2005 17:45:22 -0800 Message-Id: <44577305605619.80238449@phycomycetes> X-Mailer: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message X-Symantec-Anti-Spam: PASS Date: Thu, 01 Sep 2005 17:45:22 -0800 To: bounces-ietf@ietf.org Cc: 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, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org From: "Andre Rodriguez" Subject: No regrets rates fixed Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_12613592==.REL" X-Spam-Score: 4.4 (++++) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 --=====================_12613592==.REL Content-Type: multipart/alternative; boundary="=====================_08773116==.ALT" --=====================_08773116==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable may booklet ! chummy see relief try exaltation some betsey the intuit on batch some cashmere ! copter in tasteful see campanile it vocalic see ant in plethora it salivate the sirius see gaslight be bong it meal. --=====================_08773116==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 3D""

interfere the boastful or , circa , some officialdom not on craggy it's see vigilant it try blackbody ! or auric trya communique may.
try garlic be or phenol see be documentary ! may ivanhoe it it sibley the ! freshwater , but compline mayand sicilian and.
No, so its here
--=====================_08773116==.ALT-- --=====================_12613592==.REL Content-Type: image/gif; name="craven.3.gif"; x-mac-type="5A685745"; x-mac-creator="6A990411" Content-ID: <4.0.0.05.0.05467727835230.40126527@lectern.msn.com.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="craven.3.gif" Content-Transfer-Encoding: base64 R0lGODlhGAJKAZEAAP8AADMAmQAAAP///yH5BAAAAAAALAAAAAAYAkoBAAL/nI+py+0Po5y0 2ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMneA5eAoQ0oT0erhO rdNtVNsMi8fk8ggapWbV6fZasUUbvF6z/Y7Pj9F06zvuF7gAyKVneIiYONPlVuf2BhfJgFWo aHmJmZnB2MfmKQgp6ahJWmp6yhn6ODcpOXgKGytrGVfXCfoJaasqN+v7C/xT1fs1CpZFSdWr 5Ugc/AwdLT1NXW19jZ2tvc3d7f0NHi4+Tl5ufo6err7O3u7+Dh8vP09fb3+Pn6+/z9/v/w8w oMCBBAsaPIgwocKFDBs6fAgxosSJFCtavIgxo8aN/xw7evwIMqTIkSRLmjyJMqXKlSxbupxQ BVNMRTNfjmMmx1mlJDq/XOg5BKgFoT9HzTFagugkpDiUVnCqCYpUOkwNQS1zFULWCD23bvDq U1jVos+mhi3mLBkytQ+OacWyjC3apU9rHpXbwG2xvWvxOkjLlpkyvW3V4uxr1y2YuIYFc3V8 NytktM30Hh5MDPLlt5MtTx2bA3AXo5mpSshJ1bNj1IOQgi2N7LTp2GfvYoB9lHbt3Y91887d WjdOW2Z9wyQ9+61t4LuHEafLnE9csrVZ0wYbAzBzZXD8tiacd/TZycbL9+Zi92/ysLipY2as fahn6N0Vi59eHXTw7ub38//fzt5zSyUD1Gu1cLeddETEp5NQUBnok4IATkihcuHJ5puE/Z0n nGuVyZehh/QVUhxw+NXl34MiAqjhb+Ott1Nd7eGHHQwMIreTimQVJx2O/lEwo34vcpeYkD8G mBxuOvJlooAnkijedU4aqaF1Fg7J4oFSIjiTlQECWWSITC7XlH2aXUZeYd69R+CZq22m3ptr 1idal+CF5yYlac51nGrGpCdnZ3LNSSd6kgWGqKB12gloele+RydjNvFTIziVTkrQpd1oimlA hJrzaaeijkpqqaaeimqqqq7KaquuvgprrLLOSmuttt6Ka6667sprr77+Cmywwg5LbLHGHots ssr/Lstss84+C2200k5LbbXWXlsWp19pa1CoNjJV5KJgNhout4gMd4K5mxiZrp/wOTrgn43N 62ibn6Vmr1fqnlFvTS16qZ6Y0cHYwr4otEiCwSDa8K+WTY67H41TVmKlks9tpfAHJWI2IsAX JpgkwSxkbEKipY1Gpcn48hlZyiobWpm3X24ZG8YNOjzzwwJH+GdzOMdJb8yh3vlxcDfnKKSX FYscaX7lMhr0uzBLve6JFveJZdZWJ11lyMY5dxzIID893Y1cTrzzxi1TzG58PrfN9IBG+9gh hmIPvOHUXaN3ZJMCYulv3BzifXbYTgf+9tAhm4lohd+dDNuhvBFGeeN1/2t3teEI+iyfzFlW /p+LoW9dd288wtgV3ZAvzSa7oRNO83ms1/zhwlnH+N9VqXPeudu40x6jpK8XrnnpeaeYsujt bb5kfsbrePrXKyLNvNfHg0k9kbo73CPfvz/G/fQRJz8+8Vcuvznb6g9WPvDYZ3892y5XJXH1 9cGvteDa54x+7N1LORvEcUBRN/sUulomvKmBT2XEiZpTKichOOEJZfgSmtA+J69IoQZeE7Sg AmVDtBEZCjEevB/MmgapBTLOgvJiod5I+EFsyYJkM3Sd42Q4LAjh0FghfJwNdwjEIApxiEQs ohGPiMQkKhGEQeFgCJwYCyiKBU8nrOJHjtY3Hv8U6IePShgXQ/NFGuClMWkL40R2FwQaZvGJ ZmRYG7/1GzLeTXQJ0dMGWxg4KcKQhCVUIXz49rQYqiloL0SMB8Czp4BZ0Y5cI5celRcl2N3u IU+Ko4ciyRmnIY+Pw0tfboIEQKzhz5LxK0wZUWS/OSrSeTf0HpRSKUlK3qd238uZhSrJyeJ9 z5F2KqWLyFNAz8VrdbaDnVlU9DJU5vJ2HmvIAc2Dxu2p0pPvy2Kj6CPN0dGSmtvakM3g98xV bhFD4zTeJB0STlKyMpu4bOUqO6k2NNJxl7WoXTPZZzcBznN4S0uk/GA5yHcqDXVqREfXgJnH HqYQgRrs07ti4hwXLhP/aKuDnCDdWUjKzC9f9tzoHb8Zr4Ua0pWrKmi23ogKlPrKpMFg6RKX IMyXynSmNK2pTW+K05zqdKc87alPfwrUoAp1qEQtqlGPitSkKnWpTG2qU58K1ahKdapUrapV r4rVrGp1q1w9IgC+CoKvAgAHYh1rCcSqAbTSQK1DYKsH3DqLshoArngAa1jN+gG7MkCvKOCr CfxqAcDCQLCAFawLDJtWvP6Cr4gtQ2Mv8NjAKnYGkX3rZCVrg8rO9bIv0CwFPIsJsIoWr2Xl bANKm4DSMlauElBtall7ANWaVgGuRQBqbQvb2N52s7nNLW/hKtsIBFe3wK0tBIz728ki9wHI /x1ucl/r2+gu1wG7HYBzmVvd5xK3uL01LlrdulzvXlcGo7WuWfWqWfQqt7CknS1ty7tZ3b62 AnblrnnlG1/8gpeu+YXuffPL39NeVr3+/Wx924vf/wb4vbwtMG4TfGDOshez/TWvexeg1tUm 2ML//S2GCXve9Y6VwBzW74VZINsQZ5e62QXxigXcXxJvWLjuPfB29yvg2YI4xgiewIQr3GEf 9zi5Q05vjSUs3hkDOcitHTKTaTzj5oYYt6Y1rI0f3GHEXrkGKV4ylIG8Y8hOmcfzNTCLybxX HQc4zDIG7Y+ZDFo0Z7nIJ/aykp8sZyzrWcgbjvOc9azhIPvWzlsGsP+T3+vnvw430REus6Pp O+Y/Y7myMjb0nfMM30eb2MR1VnKl8YzdSDc6z2cGM5LTfOcfG7nPnaZyhUdtafm+eb7FlbNf B13iFhR6ujmGbXhf/GHx8hfXaebubn+93xFn2LldJrKQjS3iBUNXusfmdbBv3eLqMvu6xC72 ars9bbouetzKVu+gpQztDxebV4lGVrvbPSt4G4vRra4VsKcF7mt3dd/87re//w3wgAt84AQv uMEPjvCEK3zhDG+4wx8O8YhLfOIUr7jFL47xjGt84xzvuMc/fhuX8kulLCOpmsIRU1mSXIM0 FDm/NPazknfRCStPCrhqPq56akOeIkSlGl3/LgKD1amaPQC6e2jOzWnw3IvEZN8jKbPIiDbw UAnFYuvgxh+qN30tTIKTPzO6NhAGco8TZWAF96mcEinUigicOtzsNSave0vujmwo0ABqy5PP jpn6MyfY6IlRaqpN79aL3Zhi+U68Q0efkvLd7/r1ddNF6Z7aNPk5sYk2ro8y8Vy3OuL5SdDA 21JQiXvkQCeERcmB3ZT5W1+F1p50yied76i/eSc/icmiBOrpCPXh9sLEu9VzXmePNyAtMye7 wvOslqxfZ88eR/Q1Ll75owdNNis/c7/HvJyxn+W23uSe/qG9+Xn3fPQNnzelgFJ75LNOuG5/ vsz3Z+4xFz3/Qq9P/8V/jHTxByjCIAl/x9RAOWdH1AF8zCdOFyN+2NEwFLJ+w+R2vudHH5VA bOJQbgdREjR+DFUoE3h2dkdANiMuYodHVydSBxSC8+JzGHiBFHhRHYRHFSRRYmeCbVdPT/cN Rgdy5aCDO3gTOOiDQSiEQ0iERWiER4iESVgEQHguBXQDTCg3vVMy6gKFnIFzOtCDs8dGIJCF PrB0GnAp3KIvVwh/2beBunRGJNeFRSc+3QSGKjWGKsCAbdgBa5gCgwJ7bSdSMpcmGuh7EUiC faRCFniBgPRQezh/yFF1GOhRbAd1ZfiHbOeHEriHdKd1jMhEi4iFx8c1ZHJOouF85LN5Uf+4 d83XeJ2YJaFoTomIfbbRTqzHeNR3hg64HkCYgauYOrlXNOIHi7IoRiVoN6w0Oc/Hf4Ozirso g42IfjCYQd13J18od9PEIQ/FggjYc7SnTKX4S/W3SVo4fYhYAw6CisLoeNXnS1bXPLKHjOZD ft9RS+pHh+X0ignYfeURh604i62Xiu3Tf97Ij9b4Ag/Yi39Tjg14eIqkjVR0ebdUP8b4Ss9j ffFoe84XjK/4P/54e6cnI8bUUexIjxgJJbJYhW+4e283djaIkmS3QI7IjC/YkhqFTHkUdwxU g+GUJ/RCgIeYS+nUQSjEgVZ4khzDR420dYH4k/i0B2QofUqodEr/CYlMCQx5+H12CJVVaZVX iZVZqZVbyZVd6ZVfCZZhKZZjSZZlaZZniZZpqZZryZZt6ZZvCZdxKZdzSZd1aZfgEAB5mZcG oJd6uQB9uZcIAJiCCZiB6QCFaZiIeQCFmQCKGQF9qQCIGQB8CZkVMJiEaZiUyZgD4JiLeZmc +ZmV6ZdRtZejSZkPkJmnaZqqOZkSEJip+ZqteZqg2ZitmZqHeZugOZmZWZqy+Zi7yZu26Zu6 SZueOZu1GZnC6ZnCOZxMlZvHyQCw2ZyYOZ0NEJvIKZ3QSZvPGZ256ZfBqZ3WWZ3guZzFqZmr aZzIaZ6SSZrVaZ7dqZ7d6Z7yiZ6fOZvS/4meuPme50me3Bmf/xmclXme4pmcx8meUMWd11mg hImb/rmg2Ymft9mbEzChtSmgxemg6bmg0LmZAwqfFhqg9tlUCaqcGxqeDJqh6ZmdfwmcJuqa F8qfvqmgEPCc5BmjDKqf2CmjLZqiRTWjGDqdElqiKjqfOLqi/TmcP0qg2tmbO7qfqDmkQKqj TpqjRiqbNoqgpnmgy1mfXdqkNNqZYTqaidmh4tmkV9qhIvqbQhqhWgqjN+qhZ6qZd0mndWqn d4qneaqnsyKZfeqnfwqogSqog0qohWqoh4qoiaqob7qnjeqojwqpkSqpk0qplWqpl4qpmaqp m8qpneqpnwqqof/aCqJKqqVKVCMZhUCQcnP5TPtClcOnB+K4bwLoS2iIdLTglEdFq2F3gogE ezapgqYXgsIHgR/ldNQYiFMHKUWpqxlUjHthUYbzrP/HeQDDhHtzNydTTKB3JrWqU2ZDiMTn icnnf9zYc9b6Q9hKkSCJgJETSZMoVOAqSQjjOZazrsGIi1wkR/dqf+n3IWqXq0Ykr0jikYN3 d+V6kNUaerpHkAq4TdL6fMAje6haRDe5iDcId/TnQ3YHlI4YeX3jqxzlOg5EQe7ysBn3qkEX sGWyslqVsltIEy2bVasqFi9rqjeLszmLEMPBsz3rsz8LtEErtENLtEVrtEeLtEmrtDb/q7NN 67RPC7VRK7VTS7VVa7VXi7VZq7Vby7Vd67VfuysyC7ZjS7YqQbFlO0HjenQtKLaemoFtVClM G6mtanbhWjzwirUoSFCKqK8xg7Z0a6+W14sAmbW7iq4hBbGEm7doc4APSa5aeLacykjLpCgy l7Z2q3loq7mby7md67mfC3JLK7qjy7Oga7qni7r3gLets5IzqZNDWYmQR4Em2UJfSa3dmEld hzMNCLAHeU0CJE3AJ7f/ZrBm+Ie7G0AKmHcm5E26WDSvM7z9ZrJ044FzRK28iHuzJ5Xcl49D WLzPW73k6Bfuinal0yYbyL3Ry286BD2T17DbOErzIY3GO49QR3m7+ChQyeuRtWe98ne/udOR SKmEqztRl5tQQsc6kcExOFnAAhWBApy6ESzBE0xBFWzBZkc6GazBG8zBSHvBHdpCISzCQVAA ADs= --=====================_12613592==.REL-- From capwap-admin@frascone.com Fri Sep 02 02:17:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB4rU-0003Xw-3G for capwap-archive@megatron.ietf.org; Fri, 02 Sep 2005 02:17:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16259 for ; Fri, 2 Sep 2005 02:17:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50EAB2060A; Fri, 2 Sep 2005 02:17:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7685320544; Fri, 2 Sep 2005 02:17:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76D2C20544 for ; Fri, 2 Sep 2005 02:16:09 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 0BB412041D for ; Fri, 2 Sep 2005 02:16:06 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 01 Sep 2005 23:16:06 -0700 X-IronPort-AV: i="3.96,163,1122879600"; d="scan'208"; a="338253518:sNHT59061588" 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 j826FdQc013488 for ; Thu, 1 Sep 2005 23:15:58 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 23:15:59 -0700 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] Expanded discussion on regulatory certification Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC86011D@xmb-sjc-237.amer.cisco.com> Thread-Topic: [Capwap] Expanded discussion on regulatory certification Thread-Index: AcWvLvqHN5CmvRhOT8KiQcBCRo3f3gAVXBHA From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 02 Sep 2005 06:15:59.0003 (UTC) FILETIME=[C9242EB0:01C5AF85] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 1 Sep 2005 23:15:57 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dan, It is not Cisco that determines whether a Cisco AP is compliant. It is = the FCC (in the US) and only the FCC that makes that determination. = There are similar regulatory agencies in most other countries, as I am = sure you are aware. What Cisco can do, is determine whether a = modification to our AP is "authorized", as that term is used in the CFRs = I cited in my previous posting. =20 If Cisco determines that the modification to the AP is not authorized, = then our certification of that device no longer applies and the US = federal regulations require that the person or entity that is now "the = responsible party", the one that made the modification, must now relabel = the device (again, from the regulations I cited in my last posting) or = certify it themselves (which also requires relabeling, according to the = regulations). One nit on a statement of yours, below. I did not say in any of my = postings that modification of a Cisco (or any other) AP would "get Cisco = upset". What I did say is that the regulations require that whoever = would make such a modification now has obligations under the FCC = regulations, which include relabeling and, possibly, recertification. I = do not believe that you have presented any reasonable argument to = disprove my position. -Bob =20 -----Original Message----- From: Dan Harkins [mailto:dharkins@trpz.com]=20 Sent: Thursday, September 01, 2005 12:48 PM To: David Case (davecase) Cc: Bob O'Hara (boohara); capwap@frascone.com Subject: Re: [Capwap] Expanded discussion on regulatory certification=20 David, Thanks for the explaination. So it is Cisco and Cisco only that can determine whether a change keeps a Cisco AP in compliance and that it is the policy of Cisco to say that any change done by a 3rd party makes the AP non-compliant. Regardless of the change, right? It was modified, Cisco didn't do it, so it doesn't matter... non-compliant. If a 3rd party modifies the software of a Cisco AP it does so "at [its] own risk" and Cisco would probably void the warranty. I understand why Cisco would have such a policy. Other companies may have other policies though. And since this is about a technical feature in an protocol under consideration of the IETF I think one particular corporate policy is irrelevant. The mere fact that an image has been downloaded does not mean the AP is immediately non-compliant. Apparently it can be used in a way to trigger certain corporate action but so what? I'm sure you'll agree that just because someone can take a gun and shoot oneself in the foot does not, in and of itself, mean that guns must be forbidden. Similarly with image download. You and Bob say that it could be used in a way to get Cisco very upset. OK, fine. It can also be used in other ways: - discount AP vendor shares particulars of AP HW for AC vendor to port code to. Discount AP vendor is happy because that means more sales for his APs. AC vendor is happy because he'd rather not be in the low-margin business of building APs. - company with standalone, "fat APs" enters into relationship with=20 AC vendor to OEM an AC and turn its "fat APs" into "thin", managed-by-AC APs running code developed by AC vendor. Now company can offer customers a choice-- fat or (OEM'd) thin.=20 - use your imagination.... Image download is useful and valuable. It does not immediately void certifications of APs, as I've been saying all along, and I still think it has to be included in the resulting CAPWAP protocol. Happy hunting, Dan. On Thu, 01 Sep 2005 14:48:36 EDT you wrote > I am supposedly on PTO today but got my limit of geese this morning = and now I > have time to look at email. >=20 > If we are talking one of our AP's they may have several certifications = and or > DofC's. We are the responsible party and as the responsible party for = compli >ance it is us and not anyone else who can make the determination that = the prod >uct is still compliant. >=20 > If a third party modifies our software they do so at their own risk. = Since w >e sign the DofC or letters of verification, those letters cover only = the versi >ons we tested and models we deem to be similar, we cover no 3rd party = modifica >tions >=20 > I should point out any changes may impact other regulatory and not = just FCC.=20 > If the product should have NEBS approval or IEC 60601-1-2 approval = where the=20 >software rev is part of the approval, these changes could void these = approvals >. >=20 > Also there is little issue of product warranty which will be voided = by unaut >horized changes. >=20 > I gave a call t the FCC while driving home and they concur it is Cisco = and no >t any third party who can determine if the change still keeps the = system compl >iant if done so under out FCC approvals. >=20 > If a 3rd party wants to change it then under FCC rules they need to = label it=20 >as being modified and list themselves as the responsible party.=20 >=20 > Our manuals state that any unauthorized changes could put the user at = risk to > operate the device under FCC and other regulatory regimes. >=20 > David A. Case NCE, NCT > Cisco Systems Inc > Senior Regulatory Engineer > Corporate Compliance EMC Standards and Operations > Stonegate Corp Park > 4125 Highlander Parkway > Richfield OH 44286 > T 330-523-2139 >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf=20 >Of Dan Harkins > Sent: Wednesday, August 31, 2005 1:43 AM > To: Bob O'Hara (boohara) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Expanded discussion on regulatory certification=20 >=20 > Bob, >=20 > There's an atheros driver too that has explicit txpower parameters = passed t >o a HAL routine to transmit a packet. Mucking with that parameter would = make i >t non-compliant with the regulations.=20 >=20 > Dan. >=20 > On Tue, 30 Aug 2005 22:40:32 PDT you wrote > > Dan, > >=20 > > If I understand the driver that you reference, it has a firmware=20 > >component th at is created by Cisco embedded within it (cribbed by=20 > >reverse engineering the Cisco driver and extracting the binary that = is=20 > >downloaded to the microcoded pr ocessor on the card). It is this=20 > >portion of the driver that controls any port ion of the radio that = can=20 > >affect compliance with regulations. The portion of the driver that = is=20 > >not developed by Cisco does not have access to the portions of the=20 > >802.11 card that can change its operation in a way that would make it = non-co >mpliant with the regulations. > >=20 > > I am actually leaning in the direction that this an(4) driver would=20 > >not cause the FCC to fine anyone that might use it, because it=20 > >encompasses the Cisco mi crocode and might not be seen by the FCC as = an=20 > >unauthorized modification. The FCC might disagree with me, though,=20 > >and might require convincing to see thing s in this light. > >=20 > > I can also see an entirely reasonable interpretation of the=20 > >regulations that would say this is an unauthorized modification. > >=20 > > -Bob > > =20 > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com] > > Sent: Tuesday, August 30, 2005 8:13 PM > > To: Bob O'Hara (boohara) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Expanded discussion on regulatory = certification > >=20 > > Bob, > >=20 > > I'll get back to you on the additional regulatory citations you've > > added-- they are numerous and require some reading and analysis-- = but=20 > > I have an additional couple questions for you. > >=20 > > After I loaded freebsd on my laptop I got a driver to control a=20 > > Cisco Aironet card. It was not written by a Cisco employee. I can=20 > > modify this driver to my heart's content and continue to use my=20 > > modified driver to control that card. > >=20 > > Is it your contention that a Cisco Aironet card plugged into my=20 > > laptop loses its FCC certification? If so, is it also your = contention=20 > that the FCC will fine anyone who plugs a Cisco Aironet card into a=20 > > computer running freebsd with the an(4) driver? > >=20 > > Dan. > >=20 > > On Tue, 30 Aug 2005 13:54:40 PDT you wrote > > > Dan, > > >=20 > > > Your example of loading a different OS onto a PC (which is an=20 > > > unintentional > > r > > >adiator in FCC terms) has little to do with the issue of loading = code=20 > > >that h > >as > > > control of radio parameters, such as transmit power, frequency of=20 > > > operation > >, > > >and spectral shape of the transmitted waveform, onto an AP/WTP = (which=20 > > >the FC > >C > > >classes as an intentional radiator). The OS or other programs=20 > > >running on a > >PC > > > will have little influence over the RF emissions of that device. =20 > > > Sure, cer > >ta > > >in code loops can be created to sing a song on a nearby radio. = But,=20 > > >this is > > s > > >till within the requirements under which the PC was originally=20 > > >certified. D > >ow > > >nloading code to an AP/WTP that, for example, increases the power=20 > > >output on > >a > > >channel adjacent to the edge of a band, can cause the device to = emit=20 > > >a signa > >l > > >that is above that allowed by its certification, causing illegal=20 > > >interferenc > >e > > >in the adjacent band. > > >=20 > > > The difference is very important. It is also very important that=20 > > > this disc > >us > > >sion continue in this forum, as there are very few, if any IETF=20 > > >documents th > >at > > > directly affect whether a device is legal to operate under=20 > > > governmental emi > >ss > > >ions regulations. This might be the first time that the IETF has = had=20 > > >to con > >si > > >der this issue. I believe that many here do not yet understand the = > > >importan > >ce > > > of the issue. > > >=20 > > > But, back to our discussion. > > >=20 > > > You say that it is possible to download code to an AP/WTP that=20 > > > "would retai > >n > > >its certification". This is where there is a fundamental point on=20 > > >which we > >di > > >sagree. I do agree with you that it is possible to download code=20 > > >from a thi > >rd > > > party onto an AP that would continue to have the AP operate in a=20 > > > compliant > >ma > > >nner. But, this is entirely different from that same AP with the=20 > > >third part > >y > > >code running on it maintaining its certification. > > >=20 > > > The certification "belongs" to the manufacturer of the device that = > > > obtained > > i > > >t. It is not transferable or modifiable by anyone else, without=20 > > >express aut > >ho > > >rization of the manufacturer. Downloading code that causes access = to=20 > > >the re > >gi > > >sters of a chip, for example, that has control of the RF = transmission=20 > > >charac > >te > > >ristics of the certified device is modifying the device. > > >=20 > > > Here are additional citations from the regulations governing the=20 > > > certificat > >io > > >n of radio frequency equipment in the United States, supporting = this=20 > > >positio > >n. > > >=20 > > > 47CFR2.909 states the following: > > >=20 > > > The following parties are responsible for the compliance of radio=20 > > > frequency > > e > > >quipment with the applicable standards: > > > (a) In the case of equipment which requires the issuance by the=20 > > >Commission > >of > > > a grant of equipment authorization, the party to whom that grant = of=20 > > > authori > >za > > >tion is issued (the grantee) If the radio frequency equipment is=20 > > >modified by > > a > > >ny party other than the grantee and that party is not working under = > > >the auth > >or > > >ization of the grantee pursuant to =A7 2.929(b), the party = performing=20 > > >the modif > >ic > > >ation is responsible for compliance of the product with the=20 > > >applicable admin > >is > > >trative and technical provisions in this chapter. > > >=20 > > > 47CFR2.909 (d) states the following: > > > (d) If, because of modifications performed subsequent to=20 > > > authorization, a n > >ew > > > party becomes responsible for ensuring that a product complies = with=20 > > > the tec > >hn > > >ical standards and the new party does not obtain a new equipment=20 > > >authorizati > >on > > >, the equipment shall be labelled, following the specifications in = =A7=20 > > >2.925(d) > >, > > >with the following: ''This product has been modified by [insert = name,=20 > > >addres > >s > > >and telephone number of the party performing the modifications].'' > > >=20 > > > 47CFR2.929 states this, as well: > > > =A7 2.929 Nonassignability of an equipment authorization. > > > (a) An equipment authorization issued by the Commission may not be = > > > assigned > >, > > >exchanged or in any other way transferred to a second party. > > >=20 > > > So, for the example well below in this thread, either the third=20 > > > party WTP c > >od > > >e developer, the AC vendor that performs the unauthorized (by the=20 > > >original e > >qu > > >ipment manufacturer) download to the WTP, or possibly the customer=20 > > >that ente > >re > > >d the command to perform the download is now the party responsible=20 > > >for the c > >er > > >tification/authorization of the WTP, not the original = manufacturer. =20 > > >At a m > >in > > >imum, 47CFR2.909 (d) will require someone to physically access each = > > >modified > > W > > >TP to affix a sticker. Even without actually certifying the = modified=20 > > >WTP, t > >he > > > device is now the responsibility of someone other than the = original=20 > > > manufac > >tu > > >rer to ensure that it meets the regulatory requirements. > > >=20 > > > Because our discussion touched on the possibility that the radio=20 > > > portion of > > a > > > modified WTP might be "identical" or use "identical code" to that=20 > > > used by t > >he > > > original manufacturer of the WTP, the following definition is=20 > > > provided by t > >he > > > FCC 47CFR2.908: > > >=20 > > > 2.908 Identical defined. > > > As used in this subpart, the term identical means identical within = > > > the vari > >at > > >ion that can be expected to arise as a result of quantity = production=20 > > >techniq > >ue > > >s. > > >=20 > > > This definition does not encompass a third party changing the code = > > > operatin > >g > > >the device. > > >=20 > > > I would be very interested to understand how these regulatory=20 > > > requirements > >ca > > >n be integrated with your positions, below. > > >=20 > > > -Bob > > > =20 > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Wednesday, August 24, 2005 11:00 AM > > > To: Bob O'Hara (boohara) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > certification > > >=20 > > > Bob, > > >=20 > > > You're absolutely right. Diversion to ad hominem attacks would = not=20 > > > serve the needs of this group. And it's great that no one has=20 > > > resorted to ad hominem attacks! > > >=20 > > > In your company A-D example you have moved the goal posts. = Before=20 > > > you had stated that merely running someone else's code on an AP=20 > > > required recertification. Now you're asking whether an AP can = remain=20 > > > certified "regardless of what code [company B] might download to=20 > > > [Company D's] WTP". Well that's a different question altogether. > > >=20 > > > I believe it would be possible to download an image onto an AP=20 > > > that could make it uncompliant (it could, for example, make the AP = > > > broadcast outside legal limits) and it wouldn't matter whether the = > > > company that created the downloaded image is the same as the = company=20 > > > that certified the AP in the same place. I also believe that it is = > > > possible for a company to download an image onto another company's = > > AP and that AP would retain it's certification. > > >=20 > > > So to answer your quesiton, that depends on what kind of image=20 > > > Cisco downloaded on a Trapeze AP. You could do it right or you = could=20 > > > do it wrong. But the act of downloading the image does not void = the=20 > > > certification of the AP as you have been asserting here all along. > > >=20 > > > My laptop is FCC certified. I don't know how it got certified. I = > > > do know that it was running Windows XP when I pulled it out of the = box. > > > I hate Windows XP and immediately installled FreeBSD on it. I = don't=20 > > > believe my laptop is now in violation of FCC regulations nor do I=20 > > > feel it is necessary to get a different sticker on the bottom of = my=20 > > > laptop. I am also unaware of the FCC going after anyone who has=20 > > > installed an operating system on a computer that was different = than=20 > > > one it was shipped with. > > >=20 > > > You have been unable to demonstrate how image download voids an=20 > > > AP's certification and the snippets of FCC regulations you = supplied=20 > > > did not say anything on that subject. Similarly I have been unable = > > > to demonstrate that image download will not void an AP's = certification. > > > So to answer your last question, yes, we disagree. Unless you can=20 > > > come up with an FCC ruling that refers to the issue at hand and=20 > > > unambiguously states it voids an AP's certification then I think = we=20 > > > should just let this thread die a well-deserved death right here. > > >=20 > > > Dan. > > >=20 > > > On Mon, 22 Aug 2005 16:15:28 PDT you wrote > > > > Dan, > > > >=20 > > > > Diversion to ad hominem attacks does not serve the needs of this = > > > > discussion or of this group. > > > >=20 > > > > If, as you say, there are APs out there today that have been=20 > > > > certified with code from the AP vendor that are now running code = > > > > from a third party (where the AP has not been recertified to run = > > > > with that code), I have to assume that you have personal = knowledge=20 > > > > of these implementations. If you would, please provide a list = (or=20 > > > > at least one > > > > example) that might be provided to the FCC as an example for = them=20 > > > > to resolve the question directly. > > > >=20 > > > > As I said, the code from the ART program used to certify our APs = > > > > and the parameters under which those APs are certified are = running=20 > > > > in the shipping AP under our controller. I am not sure which = part=20 > > > > of that statement is unclear. The fact that this code is = further=20 > > > > integrated into a larger program that performs a number of=20 > > > > functions that do not impact the radio or its RF characteristics = > > > > is irrelevant to the certification. Even if such a larger = program=20 > > > > were to modify the RF characteristics, it is possible, with=20 > > > > limitations, for the manufacturer of the AP to file a = "permissive=20 > > > > change" with the FCC to maintain its certification. The only=20 > > > > reason we might be able to do this is because we are the = manufacturer o >f the AP and have previously certified the AP. > > > > An arbitrary third party is not allowed this freedom. > > > >=20 > > > > Let me be clearer also about the example and question from my = last=20 > > > > email. > > > >=20 > > > > Let's say Company A is a developer of AP/WTP download modules. > > > > Company B is an AC vendor that has licensed a module from = Company=20 > > > > A for download through SLAPP. > > > > Company C is the customer that has deployed the WLAN. > > > > Company D is the manufacturer of the AP/WTP that has certified = the=20 > > > > device running their own code. > > > >=20 > > > > Your answer to my question below indicates to me that, if Cisco=20 > > > > were Company B and Trapeze were Company D, you believe that the=20 > > > > Trapeze certification of the AP/WTP would stand, regardless of=20 > > > > what code Cisco might download to the Trapeze AP/WTP. Am I=20 > > > > correct in my interpretation of your answer? > > > >=20 > > > > If I am correct in interpreting your answer to the question, I=20 > > > > disagree with your answer. I would find it wildly unlikely that = > > > > Trapeze would stand up and claim that their AP/WTP hardware is=20 > > > > fully compliant with the regulations when that hardware is = running=20 > > > > any code but their own. I am almost certain (though I don't = speak=20 > > > > for the company on this) that Cisco would not agree that our AP=20 > > > > would always operate within the regulations when running any = code than=20 >that supplied by Cisco. > > > >=20 > > > > Perhaps you disagree? > > > >=20 > > > > -Bob > > > > =20 > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > Sent: Monday, August 22, 2005 1:59 PM > > > > To: Bob O'Hara (boohara) > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > > certification > > > >=20 > > > > Bob, > > > >=20 > > > > There's nothing cute about it. You're spreading FUD-- Fear = (the=20 > > > > FCC will fine me!), Uncertainty (they don't recertify but I = think=20 > > > > we might have to), and Doubt (he was wearing his "technical = advisor hat >" > > > > and that must mean something). In fact, it's the opposite of = cute;=20 > > > > it's a big, smelly, steaming pile o' FUD. > > > >=20 > > > > If this issue is, as you say, as real as the fines the FCC = will=20 > > > > levy then there is no issue. This is being done today and the = FCC=20 > > > > is not fining anyone. > > > >=20 > > > > I was not implying any slight of hand. The thing is, you = market=20 > > > > code that did not operate the AP when it was certified and you = do=20 > > > > not recertify when you install that code on the AP. And nor = should=20 > > > > you because, as I've been saying all along, it is not necessary = to=20 > > > > recertify an AP simply because code that was not part of the=20 > > > > original certification is downloaded onto it. > > > >=20 > > > > To answer your question, company D had to have certified their = > > > > WTP prior to marketing it (they could've ran=20 > > > > ART_V48_build_13_alpha to get their certification, for = instance).=20 > > > > Since they are the company responsible for certification they=20 > > > > would supply information as may be requested concerning the=20 > > > > operation of the device to the Commission or its = representatives. > > > >=20 > > > > Dan. > > > >=20 > > > > On Mon, 22 Aug 2005 11:53:35 PDT you wrote > > > > > Dan, > > > > >=20 > > > > > The issue is not, as you put it, "just an unfortunate bunch of = FUD". > > > > > That is a cute attempt at diverting people from the issue. = But=20 > > > > > ultimately, it is futile. The folks in the CAPWAP group can=20 > > > > > research and address this issue now, or surely those that=20 > > > > > implement and deploy > > > > a > > > > > CAPWAP protocol in the future will have to address it in the = future.=20 >=20 > > > > >=20 > > > > > The requirement for certification of RF devices is not going = to=20 > > > > > go > > > > away. > > > > > Let me quote a few bits from the FCC regulations for = unlicensed > > > > devices: > > > > >=20 > > > > > Section 15.15 General technical requirements. > > > > > (b) An intentional or unintentional radiator must be = constructed=20 > > > > > such that the adjustments of any control that is readily=20 > > > > > accessible by or intended to be accessible to the user will = not=20 > > > > > cause operation of the device in violation of the regulations. > > > > >=20 > > > > > Section 15.29 Inspection by the Commission. > > > > > (c) The party responsible for the compliance of any device=20 > > > > > subject to this Part shall promptly furnish to the Commission = or=20 > > > > > its representatives such information as may be requested=20 > > > > > concerning the operation of the device, including a copy of = any=20 > > > > > measurements made for obtaining an equipment authorization or=20 > > > > > demonstrating compliance with the regulations. > > > > >=20 > > > > > Section 15.201 Equipment authorization requirement. > > > > > (b) Except as otherwise exempted in paragraph (c) of this=20 > > > > > Section and > > > > in > > > > > Section 15.23 of this > > > > > Part, all intentional radiators operating under the provisions = > > > > > of this Part shall be certificated by the Commission pursuant = to=20 > > > > > the procedures in Subpart J of Part 2 of this Chapter prior to = > > > > > marketing. > > > > >=20 > > > > > Who would you say is "the party responsible for the = compliance"=20 > > > > > of a device that has been downloaded with third party code to=20 > > > > > operate the radio in an AP under the SLAPP proposal? If, for=20 > > > > > example, Company A were to distribute code written by Company = B=20 > > > > > to Company C to download using SLAPP onto a WTP from Company = D,=20 > > > > > who is responsible for ensuring that the device is operating=20 > > > > > within the regulations? In this > > > > scenario, > > > > > who is responsible for furnishing to the Commission a copy of=20 > > > > > the measurements made for obtaining equipment authorization? > > > > >=20 > > > > > To address your other point, yes, we certify using the ART = test > > > > program. > > > > > We also incorporate the identical parameters and code required = > > > > > to maintain that certification in our operational code for the = APs. > > > > There > > > > > is no sleight of hand here, as it appears you are implying. > > > > >=20 > > > > > The issue of certification when an unauthorized third party=20 > > > > > downloads code onto a device incorporating a radio is real, as = > > > > > will be the fines levied by the FCC upon that third party (or=20 > > > > > perhaps the third party's customer, or both) for operating an = RF=20 > > > > > emitting device (an > > > > "intentional > > > > > radiator" in FCC terms) without the proper certifications. > > > > >=20 > > > > > You can try telling everyone to "ignore the man behind the = curtain" > > > > and > > > > > believe that you are living in Oz. But, in actuality, you are > > > > dreaming. > > > > >=20 > > > > > -Bob > > > > > =20 > > > > > -----Original Message----- > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > Sent: Wednesday, August 17, 2005 4:24 PM > > > > > To: Bob O'Hara (boohara) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > > > certification > > > > >=20 > > > > > Bob, > > > > >=20 > > > > > After looking at an FCC test report for the certification of = > > > > > Airespace's AS1250 it appears that you got certification not = by=20 > > > > > running your operational AP code but by running=20 > > > > > "ART_V48_build_13_alpha". So you received certification for = your=20 > > > > > APs by running code on them that is not your's and is not what = a=20 > > > > > customer runs on them. Your own operational image is loaded = onto=20 > > > > > these APs prior to shipping yet you do not recertify them with > > > > this > > > > > new code load. > > > > >=20 > > > > > So this entire issue about recertification being necessary = is=20 > > > > > just > > > > an > > > > > unfortunate bunch of FUD. > > > > >=20 > > > > > Dan. > > > > >=20 > > > > > On Thu, 04 Aug 2005 02:07:39 PDT you wrote > > > > > > <802.11 Technical advisor to CAPWAP hat> Yes, it is my=20 > > > > > > assertion that recertification is necessary. Just > > > > > because > > > > > > you suggest it may not be true, does not make it less true. > > > > > > > > > > > >=20 > > > > > > And actually, having to put another sticker on an AP has=20 > > > > > > everything > > > > to > > > > > > do with CAPWAP. Using a protocol that requires such manual > > > > operations > > > > > > at every CAPWAP AP (and not even manual operations across = the > > > > network, > > > > > > but manual operations at the top of a ladder with your head=20 > > > > > > poked > > > > into > > > > > > the hole made by moving the ceiling tile aside) hardly makes = > > > > > > for > > > > ease > > > > > of > > > > > > management or configuration consistency. It seems that a=20 > > > > > > protocol > > > > > that > > > > > > requires such manual operations does not meet Objective = 5.1.2,=20 > > > > > > configuration consistency, since the protocol cannot allow = an=20 > > > > > > AC to determine if it is legal to operate a third party WTP=20 > > > > > > after a > > > > software > > > > > > download has taken place. In the US, at least, it is not=20 > > > > > > legal to operate a Part 15.247 device (say, all 802.11b/g = APs)=20 > > > > > > without the appropriate FCCID. I am certain this is true in = > > > > > > many other > > > > regulatory > > > > > > domains, as well. > > > > > >=20 > > > > > >=20 > > > > > > -Bob > > > > > > =20 > > > > > > -----Original Message----- > > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > > Sent: Wednesday, August 03, 2005 3:29 AM > > > > > > To: Bob O'Hara (boohara) > > > > > > Cc: capwap@frascone.com > > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > > > certification > > > > > >=20 > > > > > > I was that presenter and I don't think that = recertification=20 > > > > > > is necessary, but again, that's outside my job function. > > > > > >=20 > > > > > > It may be your assertion that recertification is necessary = > > > > > > but > > > > > that's > > > > > > just your assertion, it doesn't mean it's true. And=20 > > > > > > furthermore > > > > > whether > > > > > > someone has to put a sticker on an AP has nothing to do with = CAPWAP >. > > > >=20 > > > > > >=20 > > > > > > Dan. > > > > > >=20 > > > > > > On Wed, 03 Aug 2005 03:04:21 PDT you wrote > > > > > > > At the working group meeting, I asked the presenter for=20 > > > > > > SLAPP > > > > about > > > > > > the > > > > > > > impact of downloading code into third party WTPs that have > > > > received > > > > > > > regulatory certification. At that time, the presenter = said=20 > > > > > > > that > > > > he > > > > > > was > > > > > > > not expert in that area, but suspected that = recertification=20 > > > > > > > of the device would be necessary with the newly downloaded = > > > > > > > code. I would > > > > > > like > > > > > > > to discuss this further on the list. =20 > > > > > > >=20 > > > > > > > It is my assertion that all regulatory agencies that = require=20 > > > > > > > certification of WTPs for operation in their jurisdiction=20 > > > > > > > will > > > > > require > > > > > > > that WTPs that receive code and use it for operation, when = > > > > > > > that > > > > code > > > > > > is > > > > > > > not from the entity that received the original = certification=20 > > > > > > > for > > > > the > > > > > > > device, will require a new certification of that device = with=20 > > > > > > > the > > > > > new, > > > > > > > third party code. > > > > > > >=20 > > > > > > > In addition, nearly all regulatory agencies, certainly = those=20 > > > > > > > in > > > > > North > > > > > > > America, Europe, Asia, and the Middle East, require an=20 > > > > > > > external indication of the certification, usually a = sticker=20 > > > > > > > with an > > > > > identifying > > > > > > > string. I also assert that downloading new code to a = third=20 > > > > > > > party > > > > > WTP > > > > > > > will require that all WTPs that have received that code = must=20 > > > > > > > now > > > > > also > > > > > > be > > > > > > > physically accessed to have a new sticker affixed. > > > > > > >=20 > > > > > > > It is not sufficient for an AC vendor to simply develop = code=20 > > > > > > > ports > > > > > for > > > > > > > each silicon vendor and WTP reference design from those=20 > > > > > > > silicon > > > > > > vendors. > > > > > > > The AC vendors must now obtain regulatory certification = for=20 > > > > > > > every > > > > > WTP > > > > > > > manufactured. Similarly, each WTP vendor must now obtain > > > > regulatory > > > > > > > certification with every AC vendor. > > > > > > >=20 > > > > > > > This will be a significant additional cost for all AC and=20 > > > > > > > WTP > > > > > vendors. > > > > > > > Where current devices need to be certified once for each > > > > regulatory > > > > > > > domain, SLAPP will require that each device is certified=20 > > > > > > > several > > > > > times > > > > > > > for each regulatory domain. The cost of regulatory=20 > > > > > > > certification > > > > > for > > > > > > an > > > > > > > AC vendor is now multiplied by the number of WTPs that is > > > > supports. > > > > > > > Similarly, the cost of certification for a WTP vendor is > > > > multiplied > > > > > by > > > > > > > the number of ACs that are supported. Even sharing the = cost=20 > > > > > > > of certification between AC and WTP vendor only cuts this=20 > > > > > > > cost in > > > > half. > > > > > > It > > > > > > > is still dramatically larger than with any other proposal. > > > > > > >=20 > > > > > > > This is a very important issue. With SLAPP, it is no = longer > > > > > > sufficient > > > > > > > to state support for the ultimate CAPWAP protocol to be > > > > > interoperable. > > > > > > > It is now necessary that there be a specific business > > > > relationships > > > > > > > between AC and WTP vendors or a list of "compatible" = vendors=20 > > > > > > > and > > > > > model > > > > > > > numbers. > > > > > > >=20 > > > > > > > I believe that this also significantly raises the barriers = > > > > > > > to > > > > entry > > > > > > for > > > > > > > AC and WTP vendors, since the cost of market entry is=20 > > > > > > > associated > > > > > with > > > > > > > the costs of regulatory certification with a potentially=20 > > > > > > > large > > > > > number > > > > > > of > > > > > > > ACs and WTPs. As the number of ACs and WTPs increase, = this=20 > > > > > > > cost > > > > > also > > > > > > > increases. The result is likely to be an entrenchment of=20 > > > > > > > the > > > > early > > > > > > > entrants into this market and the exclusion of new = participants. > > > > > > >=20 > > > > > > > So, my final assertion is that adoption of the SLAPP model = > > > > > > > for > > > > > CAPWAP > > > > > > > would have exactly the opposite effect that is desired = from=20 > > > > > > > standardization, which is lower costs, greater = competition,=20 > > > > > > > and > > > > > widely > > > > > > > interoperable products. > > > > > > >=20 > > > > > > > -Bob > > > > > > >=20 > > > > > > > Bob O'Hara > > > > > > > Cisco Systems - WNBU > > > > > > >=20 > > > > > > > Phone: +1 408 853 5513 > > > > > > > Mobile: +1 408 218 4025 > > > > > > > =20 > > > > > > > _______________________________________________ > > > > > > > Capwap mailing list > > > > > > > Capwap@frascone.com > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > >=20 > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > >=20 > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > >=20 > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > >=20 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 02 09:48:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBBtx-00036A-4t for capwap-archive@megatron.ietf.org; Fri, 02 Sep 2005 09:48:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06961 for ; Fri, 2 Sep 2005 09:48:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2C592063D; Fri, 2 Sep 2005 09:48:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF61D20623; Fri, 2 Sep 2005 09:48:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE5A620623 for ; Fri, 2 Sep 2005 09:47:20 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 855A42042D for ; Fri, 2 Sep 2005 09:47:15 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 02 Sep 2005 06:47:14 -0700 X-IronPort-AV: i="3.96,164,1122879600"; d="scan'208"; a="658071781:sNHT42868552" 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 j82Dl8QM011127 for ; Fri, 2 Sep 2005 06:47:09 -0700 (PDT) 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, 2 Sep 2005 06:47:01 -0700 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] Expanded discussion on regulatory certification Message-ID: <4FF84B0BC277FF45AA27FE969DD956A29C397E@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Expanded discussion on regulatory certification Thread-Index: AcWvLvqHN5CmvRhOT8KiQcBCRo3f3gAVXBHAAA/ucBA= From: "Pat Calhoun (pacalhou)" To: "Bob O'Hara (boohara)" , X-OriginalArrivalTime: 02 Sep 2005 13:47:01.0121 (UTC) FILETIME=[CB6BAF10:01C5AFC4] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 2 Sep 2005 06:47:00 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Moreover, here is a quote from a user guide from a product shipping from = another manufacturer in this space: "Changes or modifications not expressly approved by the manufacturer may = void the user's authority granted by the FCC to operate this device." So clearly there are others that have come to the same conclusion in = their interpretation of the FCC regulations. That said, folks, let's = kill this thread. We are obviously not going to come to the same = conclusion. I would, however, ask that the WG to keep in mind that FCC regulations = are complex, and interpretations of the rules may differ from one vendor = to another. As a consequence, creating a standard that places many = companies (not just Cisco, read above quote) in a situation where they = cannot implement the said standard, would not be acceptable. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara (boohara) > Sent: Thursday, September 01, 2005 11:16 PM > To: capwap@frascone.com > Subject: RE: [Capwap] Expanded discussion on regulatory certification=20 >=20 > Dan, >=20 > It is not Cisco that determines whether a Cisco AP is=20 > compliant. It is the FCC (in the US) and only the FCC that=20 > makes that determination. There are similar regulatory=20 > agencies in most other countries, as I am sure you are aware.=20 > What Cisco can do, is determine whether a modification to=20 > our AP is "authorized", as that term is used in the CFRs I=20 > cited in my previous posting. =20 >=20 > If Cisco determines that the modification to the AP is not=20 > authorized, then our certification of that device no longer=20 > applies and the US federal regulations require that the=20 > person or entity that is now "the responsible party", the one=20 > that made the modification, must now relabel the device=20 > (again, from the regulations I cited in my last posting) or=20 > certify it themselves (which also requires relabeling,=20 > according to the regulations). >=20 > One nit on a statement of yours, below. I did not say in any=20 > of my postings that modification of a Cisco (or any other) AP=20 > would "get Cisco upset". What I did say is that the=20 > regulations require that whoever would make such a=20 > modification now has obligations under the FCC regulations,=20 > which include relabeling and, possibly, recertification. I=20 > do not believe that you have presented any reasonable=20 > argument to disprove my position. >=20 > -Bob > =20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com] > Sent: Thursday, September 01, 2005 12:48 PM > To: David Case (davecase) > Cc: Bob O'Hara (boohara); capwap@frascone.com > Subject: Re: [Capwap] Expanded discussion on regulatory certification=20 >=20 > David, >=20 > Thanks for the explaination. So it is Cisco and Cisco only=20 > that can determine whether a change keeps a Cisco AP in=20 > compliance and that it is the policy of Cisco to say that any=20 > change done by a 3rd party makes the AP non-compliant.=20 > Regardless of the change, right? It was modified, Cisco=20 > didn't do it, so it doesn't matter... non-compliant. If a 3rd=20 > party modifies the software of a Cisco AP it does so "at=20 > [its] own risk" and Cisco would probably void the warranty. >=20 > I understand why Cisco would have such a policy. Other=20 > companies may have other policies though. And since this is=20 > about a technical feature in an protocol under consideration=20 > of the IETF I think one particular corporate policy is irrelevant. >=20 > The mere fact that an image has been downloaded does not=20 > mean the AP is immediately non-compliant. Apparently it can=20 > be used in a way to trigger certain corporate action but so=20 > what? I'm sure you'll agree that just because someone can=20 > take a gun and shoot oneself in the foot does not, in and of=20 > itself, mean that guns must be forbidden. Similarly with=20 > image download. You and Bob say that it could be used in a=20 > way to get Cisco very upset. OK, fine. It can also be used in=20 > other ways: >=20 > - discount AP vendor shares particulars of AP HW for AC vendor to > port code to. Discount AP vendor is happy because that means more > sales for his APs. AC vendor is happy because he'd rather not be > in the low-margin business of building APs. >=20 > - company with standalone, "fat APs" enters into relationship with=20 > AC vendor to OEM an AC and turn its "fat APs" into "thin", > managed-by-AC APs running code developed by AC vendor. Now company > can offer customers a choice-- fat or (OEM'd) thin.=20 >=20 > - use your imagination.... >=20 > Image download is useful and valuable. It does not=20 > immediately void certifications of APs, as I've been saying=20 > all along, and I still think it has to be included in the=20 > resulting CAPWAP protocol. >=20 > Happy hunting, >=20 > Dan. >=20 > On Thu, 01 Sep 2005 14:48:36 EDT you wrote > > I am supposedly on PTO today but got my limit of geese this morning=20 > > and now I have time to look at email. > >=20 > > If we are talking one of our AP's they may have several=20 > certifications=20 > >and or DofC's. We are the responsible party and as the responsible=20 > >party for compli ance it is us and not anyone else who can make the=20 > >determination that the prod uct is still compliant. > >=20 > > If a third party modifies our software they do so at their=20 > own risk. =20 > >Since w e sign the DofC or letters of verification, those=20 > letters cover=20 > >only the versi ons we tested and models we deem to be=20 > similar, we cover=20 > >no 3rd party modifica tions > >=20 > > I should point out any changes may impact other regulatory=20 > and not just FCC.=20 > > If the product should have NEBS approval or IEC 60601-1-2 approval=20 > >where the software rev is part of the approval, these changes could=20 > >void these approvals . > >=20 > > Also there is little issue of product warranty which will=20 > be voided=20 > >by unaut horized changes. > >=20 > > I gave a call t the FCC while driving home and they concur=20 > it is Cisco=20 > >and no t any third party who can determine if the change still keeps=20 > >the system compl iant if done so under out FCC approvals. > >=20 > > If a 3rd party wants to change it then under FCC rules they need to=20 > >label it as being modified and list themselves as the=20 > responsible party. > >=20 > > Our manuals state that any unauthorized changes could put=20 > the user at=20 > > risk to operate the device under FCC and other regulatory regimes. > >=20 > > David A. Case NCE, NCT > > Cisco Systems Inc > > Senior Regulatory Engineer > > Corporate Compliance EMC Standards and Operations Stonegate=20 > Corp Park > > 4125 Highlander Parkway > > Richfield OH 44286 > > T 330-523-2139 > >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > >Behalf Of Dan Harkins > > Sent: Wednesday, August 31, 2005 1:43 AM > > To: Bob O'Hara (boohara) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > certification > >=20 > > Bob, > >=20 > > There's an atheros driver too that has explicit txpower=20 > parameters=20 > >passed t o a HAL routine to transmit a packet. Mucking with that=20 > >parameter would make i t non-compliant with the regulations. > >=20 > > Dan. > >=20 > > On Tue, 30 Aug 2005 22:40:32 PDT you wrote > > > Dan, > > >=20 > > > If I understand the driver that you reference, it has a firmware=20 > > >component th at is created by Cisco embedded within it (cribbed by=20 > > >reverse engineering the Cisco driver and extracting the=20 > binary that=20 > > >is downloaded to the microcoded pr ocessor on the card). =20 > It is this=20 > > >portion of the driver that controls any port ion of the radio that=20 > > >can affect compliance with regulations. The portion of the driver=20 > > >that is not developed by Cisco does not have access to the=20 > portions =20 > > >of the > > >802.11 card that can change its operation in a way that=20 > would make it=20 > > >non-co > >mpliant with the regulations. > > >=20 > > > I am actually leaning in the direction that this an(4)=20 > driver would=20 > > >not cause the FCC to fine anyone that might use it, because it=20 > > >encompasses the Cisco mi crocode and might not be seen by=20 > the FCC as=20 > > >an unauthorized modification. The FCC might disagree with me,=20 > > >though, and might require convincing to see thing s in this light. > > >=20 > > > I can also see an entirely reasonable interpretation of the=20 > > >regulations that would say this is an unauthorized modification. > > >=20 > > > -Bob > > > =20 > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Tuesday, August 30, 2005 8:13 PM > > > To: Bob O'Hara (boohara) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > certification > > >=20 > > > Bob, > > >=20 > > > I'll get back to you on the additional regulatory=20 > citations you've > > > added-- they are numerous and require some reading and analysis--=20 > > > but I have an additional couple questions for you. > > >=20 > > > After I loaded freebsd on my laptop I got a driver to control a=20 > > > Cisco Aironet card. It was not written by a Cisco employee. I can=20 > > > modify this driver to my heart's content and continue to use my=20 > > > modified driver to control that card. > > >=20 > > > Is it your contention that a Cisco Aironet card plugged into my=20 > > > laptop loses its FCC certification? If so, is it also your=20 > > > contention > > that the FCC will fine anyone who plugs a Cisco Aironet card into a > > > computer running freebsd with the an(4) driver? > > >=20 > > > Dan. > > >=20 > > > On Tue, 30 Aug 2005 13:54:40 PDT you wrote > > > > Dan, > > > >=20 > > > > Your example of loading a different OS onto a PC (which is an=20 > > > > unintentional > > > r > > > >adiator in FCC terms) has little to do with the issue of loading=20 > > > >code that h > > >as > > > > control of radio parameters, such as transmit power,=20 > frequency of=20 > > > > operation > > >, > > > >and spectral shape of the transmitted waveform, onto an AP/WTP=20 > > > >(which the FC > > >C > > > >classes as an intentional radiator). The OS or other programs=20 > > > >running on a > > >PC > > > > will have little influence over the RF emissions of=20 > that device. =20 > > > > Sure, cer > > >ta > > > >in code loops can be created to sing a song on a nearby radio. =20 > > > >But, this is > > > s > > > >till within the requirements under which the PC was originally=20 > > > >certified. D > > >ow > > > >nloading code to an AP/WTP that, for example, increases=20 > the power=20 > > > >output on > > >a > > > >channel adjacent to the edge of a band, can cause the device to=20 > > > >emit a signa > > >l > > > >that is above that allowed by its certification, causing illegal=20 > > > >interferenc > > >e > > > >in the adjacent band. > > > >=20 > > > > The difference is very important. It is also very=20 > important that=20 > > > > this disc > > >us > > > >sion continue in this forum, as there are very few, if any IETF=20 > > > >documents th > > >at > > > > directly affect whether a device is legal to operate under=20 > > > > governmental emi > > >ss > > > >ions regulations. This might be the first time that the=20 > IETF has=20 > > > >had to con > > >si > > > >der this issue. I believe that many here do not yet=20 > understand the=20 > > > >importan > > >ce > > > > of the issue. > > > >=20 > > > > But, back to our discussion. > > > >=20 > > > > You say that it is possible to download code to an AP/WTP that=20 > > > > "would retai > > >n > > > >its certification". This is where there is a=20 > fundamental point on=20 > > > >which we > > >di > > > >sagree. I do agree with you that it is possible to=20 > download code=20 > > > >from a thi > > >rd > > > > party onto an AP that would continue to have the AP=20 > operate in a=20 > > > > compliant > > >ma > > > >nner. But, this is entirely different from that same AP=20 > with the=20 > > > >third part > > >y > > > >code running on it maintaining its certification. > > > >=20 > > > > The certification "belongs" to the manufacturer of the=20 > device that=20 > > > > obtained > > > i > > > >t. It is not transferable or modifiable by anyone else, without=20 > > > >express aut > > >ho > > > >rization of the manufacturer. Downloading code that=20 > causes access=20 > > > >to the re > > >gi > > > >sters of a chip, for example, that has control of the RF=20 > > > >transmission charac > > >te > > > >ristics of the certified device is modifying the device. > > > >=20 > > > > Here are additional citations from the regulations=20 > governing the=20 > > > > certificat > > >io > > > >n of radio frequency equipment in the United States, supporting=20 > > > >this positio > > >n. > > > >=20 > > > > 47CFR2.909 states the following: > > > >=20 > > > > The following parties are responsible for the=20 > compliance of radio=20 > > > > frequency > > > e > > > >quipment with the applicable standards: > > > > (a) In the case of equipment which requires the issuance by the=20 > > > >Commission > > >of > > > > a grant of equipment authorization, the party to whom=20 > that grant=20 > > > > of authori > > >za > > > >tion is issued (the grantee) If the radio frequency equipment is=20 > > > >modified by > > > a > > > >ny party other than the grantee and that party is not=20 > working under=20 > > > >the auth > > >or > > > >ization of the grantee pursuant to =A7 2.929(b), the party=20 > performing=20 > > > >the modif > > >ic > > > >ation is responsible for compliance of the product with the=20 > > > >applicable admin > > >is > > > >trative and technical provisions in this chapter. > > > >=20 > > > > 47CFR2.909 (d) states the following: > > > > (d) If, because of modifications performed subsequent to=20 > > > > authorization, a n > > >ew > > > > party becomes responsible for ensuring that a product complies=20 > > > > with the tec > > >hn > > > >ical standards and the new party does not obtain a new equipment=20 > > > >authorizati > > >on > > > >, the equipment shall be labelled, following the=20 > specifications in=20 > > > >=A7 > > > >2.925(d) > > >, > > > >with the following: ''This product has been modified by [insert=20 > > > >name, addres > > >s > > > >and telephone number of the party performing the=20 > modifications].'' > > > >=20 > > > > 47CFR2.929 states this, as well: > > > > =A7 2.929 Nonassignability of an equipment authorization. > > > > (a) An equipment authorization issued by the Commission=20 > may not be=20 > > > > assigned > > >, > > > >exchanged or in any other way transferred to a second party. > > > >=20 > > > > So, for the example well below in this thread, either the third=20 > > > > party WTP c > > >od > > > >e developer, the AC vendor that performs the=20 > unauthorized (by the=20 > > > >original e > > >qu > > > >ipment manufacturer) download to the WTP, or possibly=20 > the customer=20 > > > >that ente > > >re > > > >d the command to perform the download is now the party=20 > responsible=20 > > > >for the c > > >er > > > >tification/authorization of the WTP, not the original=20 > manufacturer. =20 > > > >At a m > > >in > > > >imum, 47CFR2.909 (d) will require someone to physically=20 > access each=20 > > > >modified > > > W > > > >TP to affix a sticker. Even without actually certifying the=20 > > > >modified WTP, t > > >he > > > > device is now the responsibility of someone other than the=20 > > > > original manufac > > >tu > > > >rer to ensure that it meets the regulatory requirements. > > > >=20 > > > > Because our discussion touched on the possibility that=20 > the radio=20 > > > > portion of > > > a > > > > modified WTP might be "identical" or use "identical=20 > code" to that=20 > > > > used by t > > >he > > > > original manufacturer of the WTP, the following definition is=20 > > > > provided by t > > >he > > > > FCC 47CFR2.908: > > > >=20 > > > > 2.908 Identical defined. > > > > As used in this subpart, the term identical means=20 > identical within=20 > > > > the vari > > >at > > > >ion that can be expected to arise as a result of quantity=20 > > > >production techniq > > >ue > > > >s. > > > >=20 > > > > This definition does not encompass a third party=20 > changing the code=20 > > > > operatin > > >g > > > >the device. > > > >=20 > > > > I would be very interested to understand how these regulatory=20 > > > > requirements > > >ca > > > >n be integrated with your positions, below. > > > >=20 > > > > -Bob > > > > =20 > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > Sent: Wednesday, August 24, 2005 11:00 AM > > > > To: Bob O'Hara (boohara) > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > > certification > > > >=20 > > > > Bob, > > > >=20 > > > > You're absolutely right. Diversion to ad hominem=20 > attacks would=20 > > > > not serve the needs of this group. And it's great that=20 > no one has=20 > > > > resorted to ad hominem attacks! > > > >=20 > > > > In your company A-D example you have moved the goal posts.=20 > > > > Before you had stated that merely running someone=20 > else's code on=20 > > > > an AP required recertification. Now you're asking whether an AP=20 > > > > can remain certified "regardless of what code [company B] might=20 > > > > download to [Company D's] WTP". Well that's a different=20 > question altogether. > > > >=20 > > > > I believe it would be possible to download an image=20 > onto an AP=20 > > > > that could make it uncompliant (it could, for example,=20 > make the AP=20 > > > > broadcast outside legal limits) and it wouldn't matter=20 > whether the=20 > > > > company that created the downloaded image is the same as the=20 > > > > company that certified the AP in the same place. I also believe=20 > > > > that it is possible for a company to download an image onto=20 > > > > another company's > > > AP and that AP would retain it's certification. > > > >=20 > > > > So to answer your quesiton, that depends on what kind=20 > of image=20 > > > > Cisco downloaded on a Trapeze AP. You could do it right or you=20 > > > > could do it wrong. But the act of downloading the image=20 > does not=20 > > > > void the certification of the AP as you have been=20 > asserting here all along. > > > >=20 > > > > My laptop is FCC certified. I don't know how it got=20 > certified. I=20 > > > > do know that it was running Windows XP when I pulled it=20 > out of the box. > > > > I hate Windows XP and immediately installled FreeBSD on it. I=20 > > > > don't believe my laptop is now in violation of FCC=20 > regulations nor=20 > > > > do I feel it is necessary to get a different sticker on=20 > the bottom=20 > > > > of my laptop. I am also unaware of the FCC going after=20 > anyone who=20 > > > > has installed an operating system on a computer that=20 > was different=20 > > > > than one it was shipped with. > > > >=20 > > > > You have been unable to demonstrate how image=20 > download voids an=20 > > > > AP's certification and the snippets of FCC regulations you=20 > > > > supplied did not say anything on that subject. Similarly I have=20 > > > > been unable to demonstrate that image download will not=20 > void an AP's certification. > > > > So to answer your last question, yes, we disagree.=20 > Unless you can=20 > > > > come up with an FCC ruling that refers to the issue at hand and=20 > > > > unambiguously states it voids an AP's certification=20 > then I think=20 > > > > we should just let this thread die a well-deserved=20 > death right here. > > > >=20 > > > > Dan. > > > >=20 > > > > On Mon, 22 Aug 2005 16:15:28 PDT you wrote > > > > > Dan, > > > > >=20 > > > > > Diversion to ad hominem attacks does not serve the=20 > needs of this=20 > > > > > discussion or of this group. > > > > >=20 > > > > > If, as you say, there are APs out there today that have been=20 > > > > > certified with code from the AP vendor that are now=20 > running code=20 > > > > > from a third party (where the AP has not been=20 > recertified to run=20 > > > > > with that code), I have to assume that you have personal=20 > > > > > knowledge of these implementations. If you would, please=20 > > > > > provide a list (or at least one > > > > > example) that might be provided to the FCC as an example for=20 > > > > > them to resolve the question directly. > > > > >=20 > > > > > As I said, the code from the ART program used to=20 > certify our APs=20 > > > > > and the parameters under which those APs are certified are=20 > > > > > running in the shipping AP under our controller. I=20 > am not sure=20 > > > > > which part of that statement is unclear. The fact that this=20 > > > > > code is further integrated into a larger program that=20 > performs a=20 > > > > > number of functions that do not impact the radio or its RF=20 > > > > > characteristics is irrelevant to the certification. Even if=20 > > > > > such a larger program were to modify the RF=20 > characteristics, it=20 > > > > > is possible, with limitations, for the manufacturer=20 > of the AP to=20 > > > > > file a "permissive change" with the FCC to maintain its=20 > > > > > certification. The only reason we might be able to=20 > do this is=20 > > > > > because we are the manufacturer o > >f the AP and have previously certified the AP. > > > > > An arbitrary third party is not allowed this freedom. > > > > >=20 > > > > > Let me be clearer also about the example and question from my=20 > > > > > last email. > > > > >=20 > > > > > Let's say Company A is a developer of AP/WTP download modules. > > > > > Company B is an AC vendor that has licensed a module from=20 > > > > > Company A for download through SLAPP. > > > > > Company C is the customer that has deployed the WLAN. > > > > > Company D is the manufacturer of the AP/WTP that has=20 > certified=20 > > > > > the device running their own code. > > > > >=20 > > > > > Your answer to my question below indicates to me=20 > that, if Cisco=20 > > > > > were Company B and Trapeze were Company D, you=20 > believe that the=20 > > > > > Trapeze certification of the AP/WTP would stand,=20 > regardless of=20 > > > > > what code Cisco might download to the Trapeze AP/WTP. Am I=20 > > > > > correct in my interpretation of your answer? > > > > >=20 > > > > > If I am correct in interpreting your answer to the=20 > question, I=20 > > > > > disagree with your answer. I would find it wildly=20 > unlikely that=20 > > > > > Trapeze would stand up and claim that their AP/WTP=20 > hardware is=20 > > > > > fully compliant with the regulations when that hardware is=20 > > > > > running any code but their own. I am almost certain=20 > (though I=20 > > > > > don't speak for the company on this) that Cisco would=20 > not agree=20 > > > > > that our AP would always operate within the regulations when=20 > > > > > running any code than > >that supplied by Cisco. > > > > >=20 > > > > > Perhaps you disagree? > > > > >=20 > > > > > -Bob > > > > > =20 > > > > > -----Original Message----- > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > Sent: Monday, August 22, 2005 1:59 PM > > > > > To: Bob O'Hara (boohara) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > > > certification > > > > >=20 > > > > > Bob, > > > > >=20 > > > > > There's nothing cute about it. You're spreading FUD-- Fear=20 > > > > > (the FCC will fine me!), Uncertainty (they don't=20 > recertify but I=20 > > > > > think we might have to), and Doubt (he was wearing his=20 > > > > > "technical advisor hat > >" > > > > > and that must mean something). In fact, it's the opposite of=20 > > > > > cute; it's a big, smelly, steaming pile o' FUD. > > > > >=20 > > > > > If this issue is, as you say, as real as the fines the FCC=20 > > > > > will levy then there is no issue. This is being done=20 > today and=20 > > > > > the FCC is not fining anyone. > > > > >=20 > > > > > I was not implying any slight of hand. The thing is, you=20 > > > > > market code that did not operate the AP when it was certified=20 > > > > > and you do not recertify when you install that code=20 > on the AP.=20 > > > > > And nor should you because, as I've been saying all=20 > along, it is=20 > > > > > not necessary to recertify an AP simply because code that was=20 > > > > > not part of the original certification is downloaded onto it. > > > > >=20 > > > > > To answer your question, company D had to have=20 > certified their=20 > > > > > WTP prior to marketing it (they could've ran=20 > > > > > ART_V48_build_13_alpha to get their certification,=20 > for instance). > > > > > Since they are the company responsible for certification they=20 > > > > > would supply information as may be requested concerning the=20 > > > > > operation of the device to the Commission or its=20 > representatives. > > > > >=20 > > > > > Dan. > > > > >=20 > > > > > On Mon, 22 Aug 2005 11:53:35 PDT you wrote > > > > > > Dan, > > > > > >=20 > > > > > > The issue is not, as you put it, "just an=20 > unfortunate bunch of FUD". > > > > > > That is a cute attempt at diverting people from the issue. =20 > > > > > > But ultimately, it is futile. The folks in the=20 > CAPWAP group=20 > > > > > > can research and address this issue now, or surely=20 > those that=20 > > > > > > implement and deploy > > > > > a > > > > > > CAPWAP protocol in the future will have to address=20 > it in the future.=20 > >=20 > > > > > >=20 > > > > > > The requirement for certification of RF devices is=20 > not going=20 > > > > > > to go > > > > > away. > > > > > > Let me quote a few bits from the FCC regulations for=20 > > > > > > unlicensed > > > > > devices: > > > > > >=20 > > > > > > Section 15.15 General technical requirements. > > > > > > (b) An intentional or unintentional radiator must be=20 > > > > > > constructed such that the adjustments of any=20 > control that is=20 > > > > > > readily accessible by or intended to be accessible=20 > to the user=20 > > > > > > will not cause operation of the device in violation=20 > of the regulations. > > > > > >=20 > > > > > > Section 15.29 Inspection by the Commission. > > > > > > (c) The party responsible for the compliance of any device=20 > > > > > > subject to this Part shall promptly furnish to the=20 > Commission=20 > > > > > > or its representatives such information as may be requested=20 > > > > > > concerning the operation of the device, including a copy of=20 > > > > > > any measurements made for obtaining an equipment=20 > authorization=20 > > > > > > or demonstrating compliance with the regulations. > > > > > >=20 > > > > > > Section 15.201 Equipment authorization requirement. > > > > > > (b) Except as otherwise exempted in paragraph (c) of this=20 > > > > > > Section and > > > > > in > > > > > > Section 15.23 of this > > > > > > Part, all intentional radiators operating under the=20 > provisions=20 > > > > > > of this Part shall be certificated by the=20 > Commission pursuant=20 > > > > > > to the procedures in Subpart J of Part 2 of this=20 > Chapter prior=20 > > > > > > to marketing. > > > > > >=20 > > > > > > Who would you say is "the party responsible for the=20 > compliance"=20 > > > > > > of a device that has been downloaded with third=20 > party code to=20 > > > > > > operate the radio in an AP under the SLAPP=20 > proposal? If, for=20 > > > > > > example, Company A were to distribute code written=20 > by Company=20 > > > > > > B to Company C to download using SLAPP onto a WTP=20 > from Company=20 > > > > > > D, who is responsible for ensuring that the device is=20 > > > > > > operating within the regulations? In this > > > > > scenario, > > > > > > who is responsible for furnishing to the Commission=20 > a copy of=20 > > > > > > the measurements made for obtaining equipment authorization? > > > > > >=20 > > > > > > To address your other point, yes, we certify using the ART=20 > > > > > > test > > > > > program. > > > > > > We also incorporate the identical parameters and=20 > code required=20 > > > > > > to maintain that certification in our operational=20 > code for the APs. > > > > > There > > > > > > is no sleight of hand here, as it appears you are implying. > > > > > >=20 > > > > > > The issue of certification when an unauthorized third party=20 > > > > > > downloads code onto a device incorporating a radio=20 > is real, as=20 > > > > > > will be the fines levied by the FCC upon that third=20 > party (or=20 > > > > > > perhaps the third party's customer, or both) for=20 > operating an=20 > > > > > > RF emitting device (an > > > > > "intentional > > > > > > radiator" in FCC terms) without the proper certifications. > > > > > >=20 > > > > > > You can try telling everyone to "ignore the man=20 > behind the curtain" > > > > > and > > > > > > believe that you are living in Oz. But, in=20 > actuality, you are > > > > > dreaming. > > > > > >=20 > > > > > > -Bob > > > > > > =20 > > > > > > -----Original Message----- > > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > > Sent: Wednesday, August 17, 2005 4:24 PM > > > > > > To: Bob O'Hara (boohara) > > > > > > Cc: capwap@frascone.com > > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > > > > certification > > > > > >=20 > > > > > > Bob, > > > > > >=20 > > > > > > After looking at an FCC test report for the=20 > certification of=20 > > > > > > Airespace's AS1250 it appears that you got=20 > certification not=20 > > > > > > by running your operational AP code but by running=20 > > > > > > "ART_V48_build_13_alpha". So you received certification for=20 > > > > > > your APs by running code on them that is not your's=20 > and is not=20 > > > > > > what a customer runs on them. Your own operational image is=20 > > > > > > loaded onto these APs prior to shipping yet you do not=20 > > > > > > recertify them with > > > > > this > > > > > > new code load. > > > > > >=20 > > > > > > So this entire issue about recertification being=20 > necessary=20 > > > > > > is just > > > > > an > > > > > > unfortunate bunch of FUD. > > > > > >=20 > > > > > > Dan. > > > > > >=20 > > > > > > On Thu, 04 Aug 2005 02:07:39 PDT you wrote > > > > > > > <802.11 Technical advisor to CAPWAP hat> Yes, it is my=20 > > > > > > > assertion that recertification is necessary. Just > > > > > > because > > > > > > > you suggest it may not be true, does not make it=20 > less true. > > > > > > > > > > > > > >=20 > > > > > > > And actually, having to put another sticker on an AP has=20 > > > > > > > everything > > > > > to > > > > > > > do with CAPWAP. Using a protocol that requires=20 > such manual > > > > > operations > > > > > > > at every CAPWAP AP (and not even manual operations across=20 > > > > > > > the > > > > > network, > > > > > > > but manual operations at the top of a ladder with=20 > your head=20 > > > > > > > poked > > > > > into > > > > > > > the hole made by moving the ceiling tile aside)=20 > hardly makes=20 > > > > > > > for > > > > > ease > > > > > > of > > > > > > > management or configuration consistency. It seems that a=20 > > > > > > > protocol > > > > > > that > > > > > > > requires such manual operations does not meet Objective=20 > > > > > > > 5.1.2, configuration consistency, since the=20 > protocol cannot=20 > > > > > > > allow an AC to determine if it is legal to=20 > operate a third=20 > > > > > > > party WTP after a > > > > > software > > > > > > > download has taken place. In the US, at least, it is not=20 > > > > > > > legal to operate a Part 15.247 device (say, all 802.11b/g=20 > > > > > > > APs) without the appropriate FCCID. I am certain this is=20 > > > > > > > true in many other > > > > > regulatory > > > > > > > domains, as well. > > > > > > >=20 > > > > > > >=20 > > > > > > > -Bob > > > > > > > =20 > > > > > > > -----Original Message----- > > > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > > > Sent: Wednesday, August 03, 2005 3:29 AM > > > > > > > To: Bob O'Hara (boohara) > > > > > > > Cc: capwap@frascone.com > > > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > > > > certification > > > > > > >=20 > > > > > > > I was that presenter and I don't think that=20 > > > > > > > recertification is necessary, but again, that's=20 > outside my job function. > > > > > > >=20 > > > > > > > It may be your assertion that recertification=20 > is necessary=20 > > > > > > > but > > > > > > that's > > > > > > > just your assertion, it doesn't mean it's true. And=20 > > > > > > > furthermore > > > > > > whether > > > > > > > someone has to put a sticker on an AP has nothing=20 > to do with=20 > > > > > > > CAPWAP > >. > > > > >=20 > > > > > > >=20 > > > > > > > Dan. > > > > > > >=20 > > > > > > > On Wed, 03 Aug 2005 03:04:21 PDT you wrote > > > > > > > > At the working group meeting, I asked the presenter for > > > > > > > SLAPP > > > > > about > > > > > > > the > > > > > > > > impact of downloading code into third party=20 > WTPs that have > > > > > received > > > > > > > > regulatory certification. At that time, the presenter=20 > > > > > > > > said that > > > > > he > > > > > > > was > > > > > > > > not expert in that area, but suspected that=20 > > > > > > > > recertification of the device would be=20 > necessary with the=20 > > > > > > > > newly downloaded code. I would > > > > > > > like > > > > > > > > to discuss this further on the list. =20 > > > > > > > >=20 > > > > > > > > It is my assertion that all regulatory agencies that=20 > > > > > > > > require certification of WTPs for operation in their=20 > > > > > > > > jurisdiction will > > > > > > require > > > > > > > > that WTPs that receive code and use it for=20 > operation, when=20 > > > > > > > > that > > > > > code > > > > > > > is > > > > > > > > not from the entity that received the original=20 > > > > > > > > certification for > > > > > the > > > > > > > > device, will require a new certification of that device=20 > > > > > > > > with the > > > > > > new, > > > > > > > > third party code. > > > > > > > >=20 > > > > > > > > In addition, nearly all regulatory agencies, certainly=20 > > > > > > > > those in > > > > > > North > > > > > > > > America, Europe, Asia, and the Middle East, require an=20 > > > > > > > > external indication of the certification, usually a=20 > > > > > > > > sticker with an > > > > > > identifying > > > > > > > > string. I also assert that downloading new code to a=20 > > > > > > > > third party > > > > > > WTP > > > > > > > > will require that all WTPs that have received that code=20 > > > > > > > > must now > > > > > > also > > > > > > > be > > > > > > > > physically accessed to have a new sticker affixed. > > > > > > > >=20 > > > > > > > > It is not sufficient for an AC vendor to simply develop=20 > > > > > > > > code ports > > > > > > for > > > > > > > > each silicon vendor and WTP reference design from those=20 > > > > > > > > silicon > > > > > > > vendors. > > > > > > > > The AC vendors must now obtain regulatory certification=20 > > > > > > > > for every > > > > > > WTP > > > > > > > > manufactured. Similarly, each WTP vendor must=20 > now obtain > > > > > regulatory > > > > > > > > certification with every AC vendor. > > > > > > > >=20 > > > > > > > > This will be a significant additional cost for=20 > all AC and=20 > > > > > > > > WTP > > > > > > vendors. > > > > > > > > Where current devices need to be certified once for each > > > > > regulatory > > > > > > > > domain, SLAPP will require that each device is=20 > certified=20 > > > > > > > > several > > > > > > times > > > > > > > > for each regulatory domain. The cost of regulatory=20 > > > > > > > > certification > > > > > > for > > > > > > > an > > > > > > > > AC vendor is now multiplied by the number of=20 > WTPs that is > > > > > supports. > > > > > > > > Similarly, the cost of certification for a WTP vendor is > > > > > multiplied > > > > > > by > > > > > > > > the number of ACs that are supported. Even sharing the=20 > > > > > > > > cost of certification between AC and WTP vendor=20 > only cuts=20 > > > > > > > > this cost in > > > > > half. > > > > > > > It > > > > > > > > is still dramatically larger than with any=20 > other proposal. > > > > > > > >=20 > > > > > > > > This is a very important issue. With SLAPP, it is no=20 > > > > > > > > longer > > > > > > > sufficient > > > > > > > > to state support for the ultimate CAPWAP protocol to be > > > > > > interoperable. > > > > > > > > It is now necessary that there be a specific business > > > > > relationships > > > > > > > > between AC and WTP vendors or a list of "compatible"=20 > > > > > > > > vendors and > > > > > > model > > > > > > > > numbers. > > > > > > > >=20 > > > > > > > > I believe that this also significantly raises=20 > the barriers=20 > > > > > > > > to > > > > > entry > > > > > > > for > > > > > > > > AC and WTP vendors, since the cost of market entry is=20 > > > > > > > > associated > > > > > > with > > > > > > > > the costs of regulatory certification with a=20 > potentially=20 > > > > > > > > large > > > > > > number > > > > > > > of > > > > > > > > ACs and WTPs. As the number of ACs and WTPs increase,=20 > > > > > > > > this cost > > > > > > also > > > > > > > > increases. The result is likely to be an=20 > entrenchment of=20 > > > > > > > > the > > > > > early > > > > > > > > entrants into this market and the exclusion of=20 > new participants. > > > > > > > >=20 > > > > > > > > So, my final assertion is that adoption of the=20 > SLAPP model=20 > > > > > > > > for > > > > > > CAPWAP > > > > > > > > would have exactly the opposite effect that is desired=20 > > > > > > > > from standardization, which is lower costs, greater=20 > > > > > > > > competition, and > > > > > > widely > > > > > > > > interoperable products. > > > > > > > >=20 > > > > > > > > -Bob > > > > > > > >=20 > > > > > > > > Bob O'Hara > > > > > > > > Cisco Systems - WNBU > > > > > > > >=20 > > > > > > > > Phone: +1 408 853 5513 > > > > > > > > Mobile: +1 408 218 4025 > > > > > > > > =20 > > > > > > > > _______________________________________________ > > > > > > > > Capwap mailing list > > > > > > > > Capwap@frascone.com > > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > Capwap mailing list > > > > > > > Capwap@frascone.com > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > >=20 > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > >=20 > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > >=20 > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > >=20 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 02 10:08:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCDF-00031B-1I for capwap-archive@megatron.ietf.org; Fri, 02 Sep 2005 10:08:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08207 for ; Fri, 2 Sep 2005 10:08:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CBFDA20642; Fri, 2 Sep 2005 10:08:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A40BA20623; Fri, 2 Sep 2005 10:08:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C73EF20623 for ; Fri, 2 Sep 2005 10:07:44 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 99A22204B7 for ; Fri, 2 Sep 2005 10:07:41 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 02 Sep 2005 07:07:41 -0700 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 j82E7NQW021097; Fri, 2 Sep 2005 07:07:35 -0700 (PDT) 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, 2 Sep 2005 07:07:25 -0700 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] Exisiting Implementation(s) for Submitted CAPWAP Proposals Message-ID: <4FF84B0BC277FF45AA27FE969DD956A29C3987@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals Thread-Index: AcWth/SbpyRopSaCQNGbpPljtgRRXACPjR5Q From: "Pat Calhoun (pacalhou)" To: "Dan Harkins" , "James Kempf" Cc: "Darren Loher" , X-OriginalArrivalTime: 02 Sep 2005 14:07:26.0100 (UTC) FILETIME=[A590A540:01C5AFC7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 2 Sep 2005 07:07:25 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dan has expressed a concern that acceptance of the LWAPP proposal means companies could not innovate without being sued by Cisco. However, I would like to remind the WG that Cisco has been a strong contributor to the IETF process for many years, and the hypothetical scenarios provided by Dan are just that - hypothetical, and are not representative of past or present behavior. Cisco believes strongly in standards, and wants to help this process - not hinder it. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 02 10:12:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCHB-0005Nf-Vm for capwap-archive@megatron.ietf.org; Fri, 02 Sep 2005 10:12:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08643 for ; Fri, 2 Sep 2005 10:12:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C243720642; Fri, 2 Sep 2005 10:12:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71C5420623; Fri, 2 Sep 2005 10:12:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A2C520623 for ; Fri, 2 Sep 2005 10:11:03 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id C0A61204B7 for ; Fri, 2 Sep 2005 10:10:56 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Fri, 02 Sep 2005 10:12:31 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 16C8924FA8 for ; Fri, 2 Sep 2005 10:12:27 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Sep 2005 10:05:57 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601329B9CE@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: capwap@frascone.com Subject: RE: [Capwap] Expanded discussion on regulatory certification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 2 Sep 2005 10:11:07 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA08643 Over the past few weeks, the only discussion on the CAPWAP reflector has been with regard to regulatory issues when you replace firmware on wirele= ss hardware. I thought we were designing a protocol that controls and provisions acces= s points. Generally speaking, the protocol consists of message definitions = and a state machine that runs on the protocol endpoints. I fail to see how th= is discussion moves us further towards creating a new protocol. Furthermore, one of the objective of the CAPWAP working group is to devel= op a protocol that is radio agnostic. If you are going to define a protocol that essentially downloads firmware to a WTP, then I would argue that the protocol is not only radio dependent, but radio and processor dependent. = You may as well specify that the protocol be sftp and declare the work comple= te. I would like to get back to discussing the issues that need to be resolve= d in creating a CAPWAP protocol and make some progress towards clarifying objectives and figuring out the best way of accomplishing our objectives. Cheers, Mike > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara (boohara) > Sent: September 2, 2005 2:16 AM > To: capwap@frascone.com > Subject: RE: [Capwap] Expanded discussion on regulatory certification=20 >=20 > Dan, >=20 > It is not Cisco that determines whether a Cisco AP is=20 > compliant. It is the FCC (in the US) and only the FCC that=20 > makes that determination. There are similar regulatory=20 > agencies in most other countries, as I am sure you are aware.=20 > What Cisco can do, is determine whether a modification to=20 > our AP is "authorized", as that term is used in the CFRs I=20 > cited in my previous posting. =20 >=20 > If Cisco determines that the modification to the AP is not=20 > authorized, then our certification of that device no longer=20 > applies and the US federal regulations require that the=20 > person or entity that is now "the responsible party", the one=20 > that made the modification, must now relabel the device=20 > (again, from the regulations I cited in my last posting) or=20 > certify it themselves (which also requires relabeling,=20 > according to the regulations). >=20 > One nit on a statement of yours, below. I did not say in any=20 > of my postings that modification of a Cisco (or any other) AP=20 > would "get Cisco upset". What I did say is that the=20 > regulations require that whoever would make such a=20 > modification now has obligations under the FCC regulations,=20 > which include relabeling and, possibly, recertification. I=20 > do not believe that you have presented any reasonable=20 > argument to disprove my position. >=20 > -Bob > =20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com] > Sent: Thursday, September 01, 2005 12:48 PM > To: David Case (davecase) > Cc: Bob O'Hara (boohara); capwap@frascone.com > Subject: Re: [Capwap] Expanded discussion on regulatory certification=20 >=20 > David, >=20 > Thanks for the explaination. So it is Cisco and Cisco only=20 > that can determine whether a change keeps a Cisco AP in=20 > compliance and that it is the policy of Cisco to say that any=20 > change done by a 3rd party makes the AP non-compliant.=20 > Regardless of the change, right? It was modified, Cisco=20 > didn't do it, so it doesn't matter... non-compliant. If a 3rd=20 > party modifies the software of a Cisco AP it does so "at=20 > [its] own risk" and Cisco would probably void the warranty. >=20 > I understand why Cisco would have such a policy. Other=20 > companies may have other policies though. And since this is=20 > about a technical feature in an protocol under consideration=20 > of the IETF I think one particular corporate policy is irrelevant. >=20 > The mere fact that an image has been downloaded does not=20 > mean the AP is immediately non-compliant. Apparently it can=20 > be used in a way to trigger certain corporate action but so=20 > what? I'm sure you'll agree that just because someone can=20 > take a gun and shoot oneself in the foot does not, in and of=20 > itself, mean that guns must be forbidden. Similarly with=20 > image download. You and Bob say that it could be used in a=20 > way to get Cisco very upset. OK, fine. It can also be used in=20 > other ways: >=20 > - discount AP vendor shares particulars of AP HW for AC vendor to > port code to. Discount AP vendor is happy because that means more > sales for his APs. AC vendor is happy because he'd rather not be > in the low-margin business of building APs. >=20 > - company with standalone, "fat APs" enters into relationship with=20 > AC vendor to OEM an AC and turn its "fat APs" into "thin", > managed-by-AC APs running code developed by AC vendor. Now company > can offer customers a choice-- fat or (OEM'd) thin.=20 >=20 > - use your imagination.... >=20 > Image download is useful and valuable. It does not=20 > immediately void certifications of APs, as I've been saying=20 > all along, and I still think it has to be included in the=20 > resulting CAPWAP protocol. >=20 > Happy hunting, >=20 > Dan. >=20 > On Thu, 01 Sep 2005 14:48:36 EDT you wrote > > I am supposedly on PTO today but got my limit of geese this morning=20 > > and now I have time to look at email. > >=20 > > If we are talking one of our AP's they may have several=20 > certifications=20 > >and or DofC's. We are the responsible party and as the responsible=20 > >party for compli ance it is us and not anyone else who can make the=20 > >determination that the prod uct is still compliant. > >=20 > > If a third party modifies our software they do so at their=20 > own risk. =20 > >Since w e sign the DofC or letters of verification, those=20 > letters cover=20 > >only the versi ons we tested and models we deem to be=20 > similar, we cover=20 > >no 3rd party modifica tions > >=20 > > I should point out any changes may impact other regulatory=20 > and not just FCC.=20 > > If the product should have NEBS approval or IEC 60601-1-2 approval=20 > >where the software rev is part of the approval, these changes could=20 > >void these approvals . > >=20 > > Also there is little issue of product warranty which will=20 > be voided=20 > >by unaut horized changes. > >=20 > > I gave a call t the FCC while driving home and they concur=20 > it is Cisco=20 > >and no t any third party who can determine if the change still keeps=20 > >the system compl iant if done so under out FCC approvals. > >=20 > > If a 3rd party wants to change it then under FCC rules they need to=20 > >label it as being modified and list themselves as the=20 > responsible party. > >=20 > > Our manuals state that any unauthorized changes could put=20 > the user at=20 > > risk to operate the device under FCC and other regulatory regimes. > >=20 > > David A. Case NCE, NCT > > Cisco Systems Inc > > Senior Regulatory Engineer > > Corporate Compliance EMC Standards and Operations Stonegate=20 > Corp Park > > 4125 Highlander Parkway > > Richfield OH 44286 > > T 330-523-2139 > >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > >Behalf Of Dan Harkins > > Sent: Wednesday, August 31, 2005 1:43 AM > > To: Bob O'Hara (boohara) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > certification > >=20 > > Bob, > >=20 > > There's an atheros driver too that has explicit txpower=20 > parameters=20 > >passed t o a HAL routine to transmit a packet. Mucking with that=20 > >parameter would make i t non-compliant with the regulations. > >=20 > > Dan. > >=20 > > On Tue, 30 Aug 2005 22:40:32 PDT you wrote > > > Dan, > > >=20 > > > If I understand the driver that you reference, it has a firmware=20 > > >component th at is created by Cisco embedded within it (cribbed by=20 > > >reverse engineering the Cisco driver and extracting the=20 > binary that=20 > > >is downloaded to the microcoded pr ocessor on the card). =20 > It is this=20 > > >portion of the driver that controls any port ion of the radio that=20 > > >can affect compliance with regulations. The portion of the driver=20 > > >that is not developed by Cisco does not have access to the=20 > portions =20 > > >of the > > >802.11 card that can change its operation in a way that=20 > would make it=20 > > >non-co > >mpliant with the regulations. > > >=20 > > > I am actually leaning in the direction that this an(4)=20 > driver would=20 > > >not cause the FCC to fine anyone that might use it, because it=20 > > >encompasses the Cisco mi crocode and might not be seen by=20 > the FCC as=20 > > >an unauthorized modification. The FCC might disagree with me,=20 > > >though, and might require convincing to see thing s in this light. > > >=20 > > > I can also see an entirely reasonable interpretation of the=20 > > >regulations that would say this is an unauthorized modification. > > >=20 > > > -Bob > > > =20 > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Tuesday, August 30, 2005 8:13 PM > > > To: Bob O'Hara (boohara) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > certification > > >=20 > > > Bob, > > >=20 > > > I'll get back to you on the additional regulatory=20 > citations you've > > > added-- they are numerous and require some reading and analysis--=20 > > > but I have an additional couple questions for you. > > >=20 > > > After I loaded freebsd on my laptop I got a driver to control a=20 > > > Cisco Aironet card. It was not written by a Cisco employee. I can=20 > > > modify this driver to my heart's content and continue to use my=20 > > > modified driver to control that card. > > >=20 > > > Is it your contention that a Cisco Aironet card plugged into my=20 > > > laptop loses its FCC certification? If so, is it also your=20 > > > contention > > that the FCC will fine anyone who plugs a Cisco Aironet card into a > > > computer running freebsd with the an(4) driver? > > >=20 > > > Dan. > > >=20 > > > On Tue, 30 Aug 2005 13:54:40 PDT you wrote > > > > Dan, > > > >=20 > > > > Your example of loading a different OS onto a PC (which is an=20 > > > > unintentional > > > r > > > >adiator in FCC terms) has little to do with the issue of loading=20 > > > >code that h > > >as > > > > control of radio parameters, such as transmit power,=20 > frequency of=20 > > > > operation > > >, > > > >and spectral shape of the transmitted waveform, onto an AP/WTP=20 > > > >(which the FC > > >C > > > >classes as an intentional radiator). The OS or other programs=20 > > > >running on a > > >PC > > > > will have little influence over the RF emissions of=20 > that device. =20 > > > > Sure, cer > > >ta > > > >in code loops can be created to sing a song on a nearby radio. =20 > > > >But, this is > > > s > > > >till within the requirements under which the PC was originally=20 > > > >certified. D > > >ow > > > >nloading code to an AP/WTP that, for example, increases=20 > the power=20 > > > >output on > > >a > > > >channel adjacent to the edge of a band, can cause the device to=20 > > > >emit a signa > > >l > > > >that is above that allowed by its certification, causing illegal=20 > > > >interferenc > > >e > > > >in the adjacent band. > > > >=20 > > > > The difference is very important. It is also very=20 > important that=20 > > > > this disc > > >us > > > >sion continue in this forum, as there are very few, if any IETF=20 > > > >documents th > > >at > > > > directly affect whether a device is legal to operate under=20 > > > > governmental emi > > >ss > > > >ions regulations. This might be the first time that the=20 > IETF has=20 > > > >had to con > > >si > > > >der this issue. I believe that many here do not yet=20 > understand the=20 > > > >importan > > >ce > > > > of the issue. > > > >=20 > > > > But, back to our discussion. > > > >=20 > > > > You say that it is possible to download code to an AP/WTP that=20 > > > > "would retai > > >n > > > >its certification". This is where there is a=20 > fundamental point on=20 > > > >which we > > >di > > > >sagree. I do agree with you that it is possible to=20 > download code=20 > > > >from a thi > > >rd > > > > party onto an AP that would continue to have the AP=20 > operate in a=20 > > > > compliant > > >ma > > > >nner. But, this is entirely different from that same AP=20 > with the=20 > > > >third part > > >y > > > >code running on it maintaining its certification. > > > >=20 > > > > The certification "belongs" to the manufacturer of the=20 > device that=20 > > > > obtained > > > i > > > >t. It is not transferable or modifiable by anyone else, without=20 > > > >express aut > > >ho > > > >rization of the manufacturer. Downloading code that=20 > causes access=20 > > > >to the re > > >gi > > > >sters of a chip, for example, that has control of the RF=20 > > > >transmission charac > > >te > > > >ristics of the certified device is modifying the device. > > > >=20 > > > > Here are additional citations from the regulations=20 > governing the=20 > > > > certificat > > >io > > > >n of radio frequency equipment in the United States, supporting=20 > > > >this positio > > >n. > > > >=20 > > > > 47CFR2.909 states the following: > > > >=20 > > > > The following parties are responsible for the=20 > compliance of radio=20 > > > > frequency > > > e > > > >quipment with the applicable standards: > > > > (a) In the case of equipment which requires the issuance by the=20 > > > >Commission > > >of > > > > a grant of equipment authorization, the party to whom=20 > that grant=20 > > > > of authori > > >za > > > >tion is issued (the grantee) If the radio frequency equipment is=20 > > > >modified by > > > a > > > >ny party other than the grantee and that party is not=20 > working under=20 > > > >the auth > > >or > > > >ization of the grantee pursuant to =A7 2.929(b), the party=20 > performing=20 > > > >the modif > > >ic > > > >ation is responsible for compliance of the product with the=20 > > > >applicable admin > > >is > > > >trative and technical provisions in this chapter. > > > >=20 > > > > 47CFR2.909 (d) states the following: > > > > (d) If, because of modifications performed subsequent to=20 > > > > authorization, a n > > >ew > > > > party becomes responsible for ensuring that a product complies=20 > > > > with the tec > > >hn > > > >ical standards and the new party does not obtain a new equipment=20 > > > >authorizati > > >on > > > >, the equipment shall be labelled, following the=20 > specifications in=20 > > > >=A7 > > > >2.925(d) > > >, > > > >with the following: ''This product has been modified by [insert=20 > > > >name, addres > > >s > > > >and telephone number of the party performing the=20 > modifications].'' > > > >=20 > > > > 47CFR2.929 states this, as well: > > > > =A7 2.929 Nonassignability of an equipment authorization. > > > > (a) An equipment authorization issued by the Commission=20 > may not be=20 > > > > assigned > > >, > > > >exchanged or in any other way transferred to a second party. > > > >=20 > > > > So, for the example well below in this thread, either the third=20 > > > > party WTP c > > >od > > > >e developer, the AC vendor that performs the=20 > unauthorized (by the=20 > > > >original e > > >qu > > > >ipment manufacturer) download to the WTP, or possibly=20 > the customer=20 > > > >that ente > > >re > > > >d the command to perform the download is now the party=20 > responsible=20 > > > >for the c > > >er > > > >tification/authorization of the WTP, not the original=20 > manufacturer. =20 > > > >At a m > > >in > > > >imum, 47CFR2.909 (d) will require someone to physically=20 > access each=20 > > > >modified > > > W > > > >TP to affix a sticker. Even without actually certifying the=20 > > > >modified WTP, t > > >he > > > > device is now the responsibility of someone other than the=20 > > > > original manufac > > >tu > > > >rer to ensure that it meets the regulatory requirements. > > > >=20 > > > > Because our discussion touched on the possibility that=20 > the radio=20 > > > > portion of > > > a > > > > modified WTP might be "identical" or use "identical=20 > code" to that=20 > > > > used by t > > >he > > > > original manufacturer of the WTP, the following definition is=20 > > > > provided by t > > >he > > > > FCC 47CFR2.908: > > > >=20 > > > > 2.908 Identical defined. > > > > As used in this subpart, the term identical means=20 > identical within=20 > > > > the vari > > >at > > > >ion that can be expected to arise as a result of quantity=20 > > > >production techniq > > >ue > > > >s. > > > >=20 > > > > This definition does not encompass a third party=20 > changing the code=20 > > > > operatin > > >g > > > >the device. > > > >=20 > > > > I would be very interested to understand how these regulatory=20 > > > > requirements > > >ca > > > >n be integrated with your positions, below. > > > >=20 > > > > -Bob > > > > =20 > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > Sent: Wednesday, August 24, 2005 11:00 AM > > > > To: Bob O'Hara (boohara) > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > > certification > > > >=20 > > > > Bob, > > > >=20 > > > > You're absolutely right. Diversion to ad hominem=20 > attacks would=20 > > > > not serve the needs of this group. And it's great that=20 > no one has=20 > > > > resorted to ad hominem attacks! > > > >=20 > > > > In your company A-D example you have moved the goal posts.=20 > > > > Before you had stated that merely running someone=20 > else's code on=20 > > > > an AP required recertification. Now you're asking whether an AP=20 > > > > can remain certified "regardless of what code [company B] might=20 > > > > download to [Company D's] WTP". Well that's a different=20 > question altogether. > > > >=20 > > > > I believe it would be possible to download an image=20 > onto an AP=20 > > > > that could make it uncompliant (it could, for example,=20 > make the AP=20 > > > > broadcast outside legal limits) and it wouldn't matter=20 > whether the=20 > > > > company that created the downloaded image is the same as the=20 > > > > company that certified the AP in the same place. I also believe=20 > > > > that it is possible for a company to download an image onto=20 > > > > another company's > > > AP and that AP would retain it's certification. > > > >=20 > > > > So to answer your quesiton, that depends on what kind=20 > of image=20 > > > > Cisco downloaded on a Trapeze AP. You could do it right or you=20 > > > > could do it wrong. But the act of downloading the image=20 > does not=20 > > > > void the certification of the AP as you have been=20 > asserting here all along. > > > >=20 > > > > My laptop is FCC certified. I don't know how it got=20 > certified. I=20 > > > > do know that it was running Windows XP when I pulled it=20 > out of the box. > > > > I hate Windows XP and immediately installled FreeBSD on it. I=20 > > > > don't believe my laptop is now in violation of FCC=20 > regulations nor=20 > > > > do I feel it is necessary to get a different sticker on=20 > the bottom=20 > > > > of my laptop. I am also unaware of the FCC going after=20 > anyone who=20 > > > > has installed an operating system on a computer that=20 > was different=20 > > > > than one it was shipped with. > > > >=20 > > > > You have been unable to demonstrate how image=20 > download voids an=20 > > > > AP's certification and the snippets of FCC regulations you=20 > > > > supplied did not say anything on that subject. Similarly I have=20 > > > > been unable to demonstrate that image download will not=20 > void an AP's certification. > > > > So to answer your last question, yes, we disagree.=20 > Unless you can=20 > > > > come up with an FCC ruling that refers to the issue at hand and=20 > > > > unambiguously states it voids an AP's certification=20 > then I think=20 > > > > we should just let this thread die a well-deserved=20 > death right here. > > > >=20 > > > > Dan. > > > >=20 > > > > On Mon, 22 Aug 2005 16:15:28 PDT you wrote > > > > > Dan, > > > > >=20 > > > > > Diversion to ad hominem attacks does not serve the=20 > needs of this=20 > > > > > discussion or of this group. > > > > >=20 > > > > > If, as you say, there are APs out there today that have been=20 > > > > > certified with code from the AP vendor that are now=20 > running code=20 > > > > > from a third party (where the AP has not been=20 > recertified to run=20 > > > > > with that code), I have to assume that you have personal=20 > > > > > knowledge of these implementations. If you would, please=20 > > > > > provide a list (or at least one > > > > > example) that might be provided to the FCC as an example for=20 > > > > > them to resolve the question directly. > > > > >=20 > > > > > As I said, the code from the ART program used to=20 > certify our APs=20 > > > > > and the parameters under which those APs are certified are=20 > > > > > running in the shipping AP under our controller. I=20 > am not sure=20 > > > > > which part of that statement is unclear. The fact that this=20 > > > > > code is further integrated into a larger program that=20 > performs a=20 > > > > > number of functions that do not impact the radio or its RF=20 > > > > > characteristics is irrelevant to the certification. Even if=20 > > > > > such a larger program were to modify the RF=20 > characteristics, it=20 > > > > > is possible, with limitations, for the manufacturer=20 > of the AP to=20 > > > > > file a "permissive change" with the FCC to maintain its=20 > > > > > certification. The only reason we might be able to=20 > do this is=20 > > > > > because we are the manufacturer o > >f the AP and have previously certified the AP. > > > > > An arbitrary third party is not allowed this freedom. > > > > >=20 > > > > > Let me be clearer also about the example and question from my=20 > > > > > last email. > > > > >=20 > > > > > Let's say Company A is a developer of AP/WTP download modules. > > > > > Company B is an AC vendor that has licensed a module from=20 > > > > > Company A for download through SLAPP. > > > > > Company C is the customer that has deployed the WLAN. > > > > > Company D is the manufacturer of the AP/WTP that has=20 > certified=20 > > > > > the device running their own code. > > > > >=20 > > > > > Your answer to my question below indicates to me=20 > that, if Cisco=20 > > > > > were Company B and Trapeze were Company D, you=20 > believe that the=20 > > > > > Trapeze certification of the AP/WTP would stand,=20 > regardless of=20 > > > > > what code Cisco might download to the Trapeze AP/WTP. Am I=20 > > > > > correct in my interpretation of your answer? > > > > >=20 > > > > > If I am correct in interpreting your answer to the=20 > question, I=20 > > > > > disagree with your answer. I would find it wildly=20 > unlikely that=20 > > > > > Trapeze would stand up and claim that their AP/WTP=20 > hardware is=20 > > > > > fully compliant with the regulations when that hardware is=20 > > > > > running any code but their own. I am almost certain=20 > (though I=20 > > > > > don't speak for the company on this) that Cisco would=20 > not agree=20 > > > > > that our AP would always operate within the regulations when=20 > > > > > running any code than > >that supplied by Cisco. > > > > >=20 > > > > > Perhaps you disagree? > > > > >=20 > > > > > -Bob > > > > > =20 > > > > > -----Original Message----- > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > Sent: Monday, August 22, 2005 1:59 PM > > > > > To: Bob O'Hara (boohara) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > > > certification > > > > >=20 > > > > > Bob, > > > > >=20 > > > > > There's nothing cute about it. You're spreading FUD-- Fear=20 > > > > > (the FCC will fine me!), Uncertainty (they don't=20 > recertify but I=20 > > > > > think we might have to), and Doubt (he was wearing his=20 > > > > > "technical advisor hat > >" > > > > > and that must mean something). In fact, it's the opposite of=20 > > > > > cute; it's a big, smelly, steaming pile o' FUD. > > > > >=20 > > > > > If this issue is, as you say, as real as the fines the FCC=20 > > > > > will levy then there is no issue. This is being done=20 > today and=20 > > > > > the FCC is not fining anyone. > > > > >=20 > > > > > I was not implying any slight of hand. The thing is, you=20 > > > > > market code that did not operate the AP when it was certified=20 > > > > > and you do not recertify when you install that code=20 > on the AP.=20 > > > > > And nor should you because, as I've been saying all=20 > along, it is=20 > > > > > not necessary to recertify an AP simply because code that was=20 > > > > > not part of the original certification is downloaded onto it. > > > > >=20 > > > > > To answer your question, company D had to have=20 > certified their=20 > > > > > WTP prior to marketing it (they could've ran=20 > > > > > ART_V48_build_13_alpha to get their certification,=20 > for instance). > > > > > Since they are the company responsible for certification they=20 > > > > > would supply information as may be requested concerning the=20 > > > > > operation of the device to the Commission or its=20 > representatives. > > > > >=20 > > > > > Dan. > > > > >=20 > > > > > On Mon, 22 Aug 2005 11:53:35 PDT you wrote > > > > > > Dan, > > > > > >=20 > > > > > > The issue is not, as you put it, "just an=20 > unfortunate bunch of FUD". > > > > > > That is a cute attempt at diverting people from the issue. =20 > > > > > > But ultimately, it is futile. The folks in the=20 > CAPWAP group=20 > > > > > > can research and address this issue now, or surely=20 > those that=20 > > > > > > implement and deploy > > > > > a > > > > > > CAPWAP protocol in the future will have to address=20 > it in the future.=20 > >=20 > > > > > >=20 > > > > > > The requirement for certification of RF devices is=20 > not going=20 > > > > > > to go > > > > > away. > > > > > > Let me quote a few bits from the FCC regulations for=20 > > > > > > unlicensed > > > > > devices: > > > > > >=20 > > > > > > Section 15.15 General technical requirements. > > > > > > (b) An intentional or unintentional radiator must be=20 > > > > > > constructed such that the adjustments of any=20 > control that is=20 > > > > > > readily accessible by or intended to be accessible=20 > to the user=20 > > > > > > will not cause operation of the device in violation=20 > of the regulations. > > > > > >=20 > > > > > > Section 15.29 Inspection by the Commission. > > > > > > (c) The party responsible for the compliance of any device=20 > > > > > > subject to this Part shall promptly furnish to the=20 > Commission=20 > > > > > > or its representatives such information as may be requested=20 > > > > > > concerning the operation of the device, including a copy of=20 > > > > > > any measurements made for obtaining an equipment=20 > authorization=20 > > > > > > or demonstrating compliance with the regulations. > > > > > >=20 > > > > > > Section 15.201 Equipment authorization requirement. > > > > > > (b) Except as otherwise exempted in paragraph (c) of this=20 > > > > > > Section and > > > > > in > > > > > > Section 15.23 of this > > > > > > Part, all intentional radiators operating under the=20 > provisions=20 > > > > > > of this Part shall be certificated by the=20 > Commission pursuant=20 > > > > > > to the procedures in Subpart J of Part 2 of this=20 > Chapter prior=20 > > > > > > to marketing. > > > > > >=20 > > > > > > Who would you say is "the party responsible for the=20 > compliance"=20 > > > > > > of a device that has been downloaded with third=20 > party code to=20 > > > > > > operate the radio in an AP under the SLAPP=20 > proposal? If, for=20 > > > > > > example, Company A were to distribute code written=20 > by Company=20 > > > > > > B to Company C to download using SLAPP onto a WTP=20 > from Company=20 > > > > > > D, who is responsible for ensuring that the device is=20 > > > > > > operating within the regulations? In this > > > > > scenario, > > > > > > who is responsible for furnishing to the Commission=20 > a copy of=20 > > > > > > the measurements made for obtaining equipment authorization? > > > > > >=20 > > > > > > To address your other point, yes, we certify using the ART=20 > > > > > > test > > > > > program. > > > > > > We also incorporate the identical parameters and=20 > code required=20 > > > > > > to maintain that certification in our operational=20 > code for the APs. > > > > > There > > > > > > is no sleight of hand here, as it appears you are implying. > > > > > >=20 > > > > > > The issue of certification when an unauthorized third party=20 > > > > > > downloads code onto a device incorporating a radio=20 > is real, as=20 > > > > > > will be the fines levied by the FCC upon that third=20 > party (or=20 > > > > > > perhaps the third party's customer, or both) for=20 > operating an=20 > > > > > > RF emitting device (an > > > > > "intentional > > > > > > radiator" in FCC terms) without the proper certifications. > > > > > >=20 > > > > > > You can try telling everyone to "ignore the man=20 > behind the curtain" > > > > > and > > > > > > believe that you are living in Oz. But, in=20 > actuality, you are > > > > > dreaming. > > > > > >=20 > > > > > > -Bob > > > > > > =20 > > > > > > -----Original Message----- > > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > > Sent: Wednesday, August 17, 2005 4:24 PM > > > > > > To: Bob O'Hara (boohara) > > > > > > Cc: capwap@frascone.com > > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > > > > certification > > > > > >=20 > > > > > > Bob, > > > > > >=20 > > > > > > After looking at an FCC test report for the=20 > certification of=20 > > > > > > Airespace's AS1250 it appears that you got=20 > certification not=20 > > > > > > by running your operational AP code but by running=20 > > > > > > "ART_V48_build_13_alpha". So you received certification for=20 > > > > > > your APs by running code on them that is not your's=20 > and is not=20 > > > > > > what a customer runs on them. Your own operational image is=20 > > > > > > loaded onto these APs prior to shipping yet you do not=20 > > > > > > recertify them with > > > > > this > > > > > > new code load. > > > > > >=20 > > > > > > So this entire issue about recertification being=20 > necessary=20 > > > > > > is just > > > > > an > > > > > > unfortunate bunch of FUD. > > > > > >=20 > > > > > > Dan. > > > > > >=20 > > > > > > On Thu, 04 Aug 2005 02:07:39 PDT you wrote > > > > > > > <802.11 Technical advisor to CAPWAP hat> Yes, it is my=20 > > > > > > > assertion that recertification is necessary. Just > > > > > > because > > > > > > > you suggest it may not be true, does not make it=20 > less true. > > > > > > > > > > > > > >=20 > > > > > > > And actually, having to put another sticker on an AP has=20 > > > > > > > everything > > > > > to > > > > > > > do with CAPWAP. Using a protocol that requires=20 > such manual > > > > > operations > > > > > > > at every CAPWAP AP (and not even manual operations across=20 > > > > > > > the > > > > > network, > > > > > > > but manual operations at the top of a ladder with=20 > your head=20 > > > > > > > poked > > > > > into > > > > > > > the hole made by moving the ceiling tile aside)=20 > hardly makes=20 > > > > > > > for > > > > > ease > > > > > > of > > > > > > > management or configuration consistency. It seems that a=20 > > > > > > > protocol > > > > > > that > > > > > > > requires such manual operations does not meet Objective=20 > > > > > > > 5.1.2, configuration consistency, since the=20 > protocol cannot=20 > > > > > > > allow an AC to determine if it is legal to=20 > operate a third=20 > > > > > > > party WTP after a > > > > > software > > > > > > > download has taken place. In the US, at least, it is not=20 > > > > > > > legal to operate a Part 15.247 device (say, all 802.11b/g=20 > > > > > > > APs) without the appropriate FCCID. I am certain this is=20 > > > > > > > true in many other > > > > > regulatory > > > > > > > domains, as well. > > > > > > >=20 > > > > > > >=20 > > > > > > > -Bob > > > > > > > =20 > > > > > > > -----Original Message----- > > > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > > > Sent: Wednesday, August 03, 2005 3:29 AM > > > > > > > To: Bob O'Hara (boohara) > > > > > > > Cc: capwap@frascone.com > > > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > > > > certification > > > > > > >=20 > > > > > > > I was that presenter and I don't think that=20 > > > > > > > recertification is necessary, but again, that's=20 > outside my job function. > > > > > > >=20 > > > > > > > It may be your assertion that recertification=20 > is necessary=20 > > > > > > > but > > > > > > that's > > > > > > > just your assertion, it doesn't mean it's true. And=20 > > > > > > > furthermore > > > > > > whether > > > > > > > someone has to put a sticker on an AP has nothing=20 > to do with=20 > > > > > > > CAPWAP > >. > > > > >=20 > > > > > > >=20 > > > > > > > Dan. > > > > > > >=20 > > > > > > > On Wed, 03 Aug 2005 03:04:21 PDT you wrote > > > > > > > > At the working group meeting, I asked the presenter for > > > > > > > SLAPP > > > > > about > > > > > > > the > > > > > > > > impact of downloading code into third party=20 > WTPs that have > > > > > received > > > > > > > > regulatory certification. At that time, the presenter=20 > > > > > > > > said that > > > > > he > > > > > > > was > > > > > > > > not expert in that area, but suspected that=20 > > > > > > > > recertification of the device would be=20 > necessary with the=20 > > > > > > > > newly downloaded code. I would > > > > > > > like > > > > > > > > to discuss this further on the list. =20 > > > > > > > >=20 > > > > > > > > It is my assertion that all regulatory agencies that=20 > > > > > > > > require certification of WTPs for operation in their=20 > > > > > > > > jurisdiction will > > > > > > require > > > > > > > > that WTPs that receive code and use it for=20 > operation, when=20 > > > > > > > > that > > > > > code > > > > > > > is > > > > > > > > not from the entity that received the original=20 > > > > > > > > certification for > > > > > the > > > > > > > > device, will require a new certification of that device=20 > > > > > > > > with the > > > > > > new, > > > > > > > > third party code. > > > > > > > >=20 > > > > > > > > In addition, nearly all regulatory agencies, certainly=20 > > > > > > > > those in > > > > > > North > > > > > > > > America, Europe, Asia, and the Middle East, require an=20 > > > > > > > > external indication of the certification, usually a=20 > > > > > > > > sticker with an > > > > > > identifying > > > > > > > > string. I also assert that downloading new code to a=20 > > > > > > > > third party > > > > > > WTP > > > > > > > > will require that all WTPs that have received that code=20 > > > > > > > > must now > > > > > > also > > > > > > > be > > > > > > > > physically accessed to have a new sticker affixed. > > > > > > > >=20 > > > > > > > > It is not sufficient for an AC vendor to simply develop=20 > > > > > > > > code ports > > > > > > for > > > > > > > > each silicon vendor and WTP reference design from those=20 > > > > > > > > silicon > > > > > > > vendors. > > > > > > > > The AC vendors must now obtain regulatory certification=20 > > > > > > > > for every > > > > > > WTP > > > > > > > > manufactured. Similarly, each WTP vendor must=20 > now obtain > > > > > regulatory > > > > > > > > certification with every AC vendor. > > > > > > > >=20 > > > > > > > > This will be a significant additional cost for=20 > all AC and=20 > > > > > > > > WTP > > > > > > vendors. > > > > > > > > Where current devices need to be certified once for each > > > > > regulatory > > > > > > > > domain, SLAPP will require that each device is=20 > certified=20 > > > > > > > > several > > > > > > times > > > > > > > > for each regulatory domain. The cost of regulatory=20 > > > > > > > > certification > > > > > > for > > > > > > > an > > > > > > > > AC vendor is now multiplied by the number of=20 > WTPs that is > > > > > supports. > > > > > > > > Similarly, the cost of certification for a WTP vendor is > > > > > multiplied > > > > > > by > > > > > > > > the number of ACs that are supported. Even sharing the=20 > > > > > > > > cost of certification between AC and WTP vendor=20 > only cuts=20 > > > > > > > > this cost in > > > > > half. > > > > > > > It > > > > > > > > is still dramatically larger than with any=20 > other proposal. > > > > > > > >=20 > > > > > > > > This is a very important issue. With SLAPP, it is no=20 > > > > > > > > longer > > > > > > > sufficient > > > > > > > > to state support for the ultimate CAPWAP protocol to be > > > > > > interoperable. > > > > > > > > It is now necessary that there be a specific business > > > > > relationships > > > > > > > > between AC and WTP vendors or a list of "compatible"=20 > > > > > > > > vendors and > > > > > > model > > > > > > > > numbers. > > > > > > > >=20 > > > > > > > > I believe that this also significantly raises=20 > the barriers=20 > > > > > > > > to > > > > > entry > > > > > > > for > > > > > > > > AC and WTP vendors, since the cost of market entry is=20 > > > > > > > > associated > > > > > > with > > > > > > > > the costs of regulatory certification with a=20 > potentially=20 > > > > > > > > large > > > > > > number > > > > > > > of > > > > > > > > ACs and WTPs. As the number of ACs and WTPs increase,=20 > > > > > > > > this cost > > > > > > also > > > > > > > > increases. The result is likely to be an=20 > entrenchment of=20 > > > > > > > > the > > > > > early > > > > > > > > entrants into this market and the exclusion of=20 > new participants. > > > > > > > >=20 > > > > > > > > So, my final assertion is that adoption of the=20 > SLAPP model=20 > > > > > > > > for > > > > > > CAPWAP > > > > > > > > would have exactly the opposite effect that is desired=20 > > > > > > > > from standardization, which is lower costs, greater=20 > > > > > > > > competition, and > > > > > > widely > > > > > > > > interoperable products. > > > > > > > >=20 > > > > > > > > -Bob > > > > > > > >=20 > > > > > > > > Bob O'Hara > > > > > > > > Cisco Systems - WNBU > > > > > > > >=20 > > > > > > > > Phone: +1 408 853 5513 > > > > > > > > Mobile: +1 408 218 4025 > > > > > > > > =20 > > > > > > > > _______________________________________________ > > > > > > > > Capwap mailing list > > > > > > > > Capwap@frascone.com > > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > Capwap mailing list > > > > > > > Capwap@frascone.com > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > >=20 > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > >=20 > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > >=20 > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > >=20 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 02 11:24:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDOp-0007om-4c for capwap-archive@megatron.ietf.org; Fri, 02 Sep 2005 11:24:22 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13502 for ; Fri, 2 Sep 2005 11:24:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C38A920643; Fri, 2 Sep 2005 11:24:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B00DA20623; Fri, 2 Sep 2005 11:24:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D4AEC20623 for ; Fri, 2 Sep 2005 11:23:01 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id B22AB201F6 for ; Fri, 2 Sep 2005 11:22:56 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j82FGJv1036807; Fri, 2 Sep 2005 08:16:19 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509021516.j82FGJv1036807@homebrew.trpz.com> To: "Pat Calhoun (pacalhou)" Cc: "James Kempf" , "Darren Loher" , capwap@frascone.com Subject: Re: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals In-Reply-To: Your message of "Fri, 02 Sep 2005 07:07:25 PDT." <4FF84B0BC277FF45AA27FE969DD956A29C3987@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36805.1125674179.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 02 Sep 2005 08:16:19 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Actually no, that's not the concern I expressed. My concern is that _any_ intellectual property that a company puts in its product which also happens to implement LWAPP will become fair game for Cisco. If a company asserts its rights against Cisco for using its intellectual property without a license then that company would lose its right to implement an IETF standard without a license. No one said that Cisco isn't a strong contributor to the IETF process. No one said that Cisco doesn't believe in standards. Been there, done that, got the RFC. You previously said that the royalty free license extends to companies that do not assert their own rights against Cisco "whether or not their assertions relate to LWAPP itself". If you now are saying that Cisco would never do something as underhanded as to take other companies' IPR and then wave the LWAPP club when that company complains then why don't you change the IPR notice so that it applies only to assertions against LWAPP? If you won't change the IPR notice then it is perfectly reasonable to expect Cisco to do exactly what I am hypothetically suggesting. What other motivation could there be for keeping that language? Hmmmmm? Dan. On Fri, 02 Sep 2005 07:07:25 PDT you wrote > Dan has expressed a concern that acceptance of the LWAPP proposal means > companies could not innovate without being sued by Cisco. However, I > would like to remind the WG that Cisco has been a strong contributor to > the IETF process for many years, and the hypothetical scenarios provided > by Dan are just that - hypothetical, and are not representative of past > or present behavior. Cisco believes strongly in standards, and wants to > help this process - not hinder it. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 02 12:25:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBELo-00032D-M2 for capwap-archive@megatron.ietf.org; Fri, 02 Sep 2005 12:25:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16257 for ; Fri, 2 Sep 2005 12:25:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 66DE6201F6; Fri, 2 Sep 2005 12:25:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 42011204B7; Fri, 2 Sep 2005 12:25:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3C927204B7 for ; Fri, 2 Sep 2005 12:24:30 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 7D7DC201F6 for ; Fri, 2 Sep 2005 12:24:28 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Fri, 02 Sep 2005 12:26:04 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 56D8E24FA8; Fri, 2 Sep 2005 12:25:59 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Sep 2005 12:19:30 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601329BA16@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: Dan Harkins Cc: capwap@frascone.com Subject: RE: [Capwap] Expanded discussion on regulatory certification MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 2 Sep 2005 12:24:39 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Dan, This holding pattern is quite frustrating given the schedule imposed on this standardization process. I believe there is a requirement for the CAPWAP protocol that it provide a mechanism for image download. I believe if that download mechanism should be provided either in-band or out-of-band. It would satisfy your requirement? I know that CTP has a state between Discovery and Connect phases that allows the AP to do image upgrade. I believe all of the proposed protocols have a state similar to this. Am I missing something? Cheers, Mike > Michael, > > We're kind of in a holding pattern waiting for the eval team to come >up with their draft. It's kind of hard to discuss message definitions >and a state machine right now given our current place in the process. > > As the person who is mostly responsible for keeping this horrible >thread alive I'll apologize right now. This whole thing about the FCC >fining people and APs suddenly becoming uncompliant was, as I mentioned, >FUD. It was an unfortuanate diversion that unfortunately required >responses. > > But! My motivation is not to present this as an alternative to a >complete control and provisioning protocol, but as a part. Just as it >is in SLAPP. It is useful and valuable for all the reasons I mentioned in >Paris and I want to work to make sure it is _part of_ the CAPWAP protocol >that this working group produces. = > > > I think a discovery and authentication phase followed by a choice >of full fledged 802.11 control protocol or full fledged 802.16 control >protocol or image download or ... would be very, very useful. Do you >not agree? > > Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 02 13:13:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBF6H-00089s-Tr for capwap-archive@megatron.ietf.org; Fri, 02 Sep 2005 13:13:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18390 for ; Fri, 2 Sep 2005 13:13:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3146420657; Fri, 2 Sep 2005 13:13:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D2D720650; Fri, 2 Sep 2005 13:13:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 41D1720650 for ; Fri, 2 Sep 2005 13:12:15 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 0606920647 for ; Fri, 2 Sep 2005 13:12:10 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j82GwsE9021017 for ; Fri, 2 Sep 2005 12:58:54 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j82GwrE9020974 for ; Fri, 2 Sep 2005 12:58:53 -0400 (EDT) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Closing thread - 'Expanded Discussion on regulatory certification' Thread-Index: AcWvyHDSGNbPC6XRRJSz3n1gHr+IWQABp12w From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Closing thread - 'Expanded Discussion on regulatory certification' Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 2 Sep 2005 11:12:00 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable With this - the chairs are calling for a closure to the thread on 'Expanded Discussion on regulatory certification'. To generally summarize over this protracted thread: As expressed by regulatory experts of varying degree (as well as all parties debating) - there are bound to be regulatory concerns whenever software results in changes to the RF-behavior of (commercial) devices that are subject to regulatory (FCC and other international/regional bodies') approval. The regulatory approvals may have some leeway to varying degrees per their regional and own legislation as to how soon incremental firmware revisions may need to recertify. [Likewise are - perhaps lesser and clearer - concerns related to other regulatory (or para-regulatory) approvals such as FIPS-140; which is the case with a vendor's own software revisions - that they will need incremental recertification at the minimum.] The discussion originated during the IETF63 session observations on concerns related to how a vendor can commit to regulatory compliance anymore when the device is subjected to control of software by another un-endorsed entity than the original vendor. The conclusion is that they cannot. The intended purpose was to discuss the impact on above behavior to a CAPWAP protocol. We are not seeing that established beyond the expressed concerns. The later half of the thread in general has been objective (barring explicit mention of vendors which we would like to avoid in this WG wherever possible; please keep example vendors anonymous - though it is too late for this thread) - but still not going anywhere either in allaying concerns or being more specific about the impact than it has been since the beginning. The chairs of this WG believe that this list does not need more exposure to drill-down details on RF-approval in WG's direct objectives of developing CAPWAP protocol than discussed. If anyone believes they have NEW succinct information or data that is relevant, we prefer that they check with the WG chairs before posting, so we can try to help ensure that we do not keep repeating/rehashing the same facts. Thanks, -Chairs =3D=3D=3D=3D=3D=3D _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 02 16:16:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBHxS-0000rD-IG for capwap-archive@megatron.ietf.org; Fri, 02 Sep 2005 16:16:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00532 for ; Fri, 2 Sep 2005 16:16:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C5FC2065A; Fri, 2 Sep 2005 16:16:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 91CD120647; Fri, 2 Sep 2005 16:16:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2DDF20647 for ; Fri, 2 Sep 2005 16:15:19 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id E9DDD205E2 for ; Fri, 2 Sep 2005 16:15:16 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 02 Sep 2005 13:15:14 -0700 X-IronPort-AV: i="3.96,164,1122879600"; d="scan'208"; a="209389684:sNHT59560488" 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 j82KEQ0v025113 for ; Fri, 2 Sep 2005 13:15:10 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 13:15:10 -0700 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] Expanded discussion on regulatory certification Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC86030D@xmb-sjc-237.amer.cisco.com> Thread-Topic: [Capwap] Expanded discussion on regulatory certification Thread-Index: AcWvLvqHN5CmvRhOT8KiQcBCRo3f3gAx9auw From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 02 Sep 2005 20:15:10.0933 (UTC) FILETIME=[053AF850:01C5AFFB] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 2 Sep 2005 13:15:10 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dan, To further expand upon your discussion of determination of = responsibility for compliance, as you mention in your first paragraph, = below, I quote from the Trapeze document entitled "Trapeze Regulatory = Information", Part Number: 730-9502-0017, Revision C. "The manufacturer, Trapeze Networks, is not responsible for any = interference caused by unauthorized modification of the devices included = with this product, or the substitution or attachment of connecting = cables or equipment other than supplied by Trapeze Networks. The correction of interference caused by such unauthorized modification, = substitution, or attachment is your responsibility. Trapeze Networks and its authorized resellers or distributors are not = liable for any damage or violation of government regulations that might = arise from failure to comply with these guidelines." It appears that Trapeze has a very similar interpretation of the = regulations to that of Cisco, from this statement. Can you tell me how = this statement differs from the position of Cisco on the topic? Again, the issue is not compliance with emissions regulations when = downloading unauthorized third party code. We both concede that such = third party code has the possibility of keeping a modified device in = compliance with those regulations. The issues are responsibility for = that emissions compliance after the download has taken place and = compliance with the further regulations requiring that each such = modified device must be labeled as I described in my earlier, as yet = still unanswered, email. Both the SLAPP and LWAPP protocol proposals include the ability to = download code to an AP/WTP. The difference between the two is that = CAPWAP requires an authentication signature must be validated before a = download can be used, while SLAPP has no such mechanism and specifically = allows download of code from sources other than the manufacturer or an = authorized delegate of the manufacturer. This is a significant = difference between the two protocols and needs to be considered when = evaluating the protocols during this phase of selecting the basis for = CAPWAP standardization. Going back to one of my first statements on this topic and to bring this = around again to why this discussion is important to the working group = while evaluating protocols, independent implementations of LWAPP can be = built from the protocol specification, alone. That same statement = cannot be made about SLAPP. =20 In order for a WTP to be operational after SLAPP downloads code from an = unauthorized third party onto that WTP, there must be additional = knowledge that is known to the third party that creates the download = image. That additional information is not conveyed by SLAPP, e.g., = memory size, I/O port addresses, time constants, etc. that are dependent = on the hardware design of the WTP. That information can be gained only = through communication between the manufacturer of the WTP and the third = party, outside of the SLAPP protocol. That communication might be in = the context of a business relationship with a vendor from whom the WTP = manufacturer purchased a design, reverse engineering of the WTP by the = third party, or some other means. But, in order for SLAPP to perform = the functions required by CAPWAP, that outside communication is = required. The reason this outside communication is not required for LWAPP is that = there is no third party. There is only the AC vendor and the WTP = vendor. The only image that the WTP will accept from the AC under the = LWAPP protocol is an image that is authenticated by the WTP vendor. = From that point forward, the AC and WTP communications is completely = defined by the LWAPP protocol. There is no need for any additional = protocol buried within the downloaded image to obtain a fully functional = WTP. -Bob =20 -----Original Message----- From: Dan Harkins [mailto:dharkins@trpz.com]=20 Sent: Thursday, September 01, 2005 12:48 PM To: David Case (davecase) Cc: Bob O'Hara (boohara); capwap@frascone.com Subject: Re: [Capwap] Expanded discussion on regulatory certification=20 David, Thanks for the explaination. So it is Cisco and Cisco only that can determine whether a change keeps a Cisco AP in compliance and that it is the policy of Cisco to say that any change done by a 3rd party makes the AP non-compliant. Regardless of the change, right? It was modified, Cisco didn't do it, so it doesn't matter... non-compliant. If a 3rd party modifies the software of a Cisco AP it does so "at [its] own risk" and Cisco would probably void the warranty. I understand why Cisco would have such a policy. Other companies may have other policies though. And since this is about a technical feature in an protocol under consideration of the IETF I think one particular corporate policy is irrelevant. The mere fact that an image has been downloaded does not mean the AP is immediately non-compliant. Apparently it can be used in a way to trigger certain corporate action but so what? I'm sure you'll agree that just because someone can take a gun and shoot oneself in the foot does not, in and of itself, mean that guns must be forbidden. Similarly with image download. You and Bob say that it could be used in a way to get Cisco very upset. OK, fine. It can also be used in other ways: - discount AP vendor shares particulars of AP HW for AC vendor to port code to. Discount AP vendor is happy because that means more sales for his APs. AC vendor is happy because he'd rather not be in the low-margin business of building APs. - company with standalone, "fat APs" enters into relationship with=20 AC vendor to OEM an AC and turn its "fat APs" into "thin", managed-by-AC APs running code developed by AC vendor. Now company can offer customers a choice-- fat or (OEM'd) thin.=20 - use your imagination.... Image download is useful and valuable. It does not immediately void certifications of APs, as I've been saying all along, and I still think it has to be included in the resulting CAPWAP protocol. Happy hunting, Dan. On Thu, 01 Sep 2005 14:48:36 EDT you wrote > I am supposedly on PTO today but got my limit of geese this morning = and now I > have time to look at email. >=20 > If we are talking one of our AP's they may have several certifications = and or > DofC's. We are the responsible party and as the responsible party for = compli >ance it is us and not anyone else who can make the determination that = the prod >uct is still compliant. >=20 > If a third party modifies our software they do so at their own risk. = Since w >e sign the DofC or letters of verification, those letters cover only = the versi >ons we tested and models we deem to be similar, we cover no 3rd party = modifica >tions >=20 > I should point out any changes may impact other regulatory and not = just FCC.=20 > If the product should have NEBS approval or IEC 60601-1-2 approval = where the=20 >software rev is part of the approval, these changes could void these = approvals >. >=20 > Also there is little issue of product warranty which will be voided = by unaut >horized changes. >=20 > I gave a call t the FCC while driving home and they concur it is Cisco = and no >t any third party who can determine if the change still keeps the = system compl >iant if done so under out FCC approvals. >=20 > If a 3rd party wants to change it then under FCC rules they need to = label it=20 >as being modified and list themselves as the responsible party.=20 >=20 > Our manuals state that any unauthorized changes could put the user at = risk to > operate the device under FCC and other regulatory regimes. >=20 > David A. Case NCE, NCT > Cisco Systems Inc > Senior Regulatory Engineer > Corporate Compliance EMC Standards and Operations > Stonegate Corp Park > 4125 Highlander Parkway > Richfield OH 44286 > T 330-523-2139 >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf=20 >Of Dan Harkins > Sent: Wednesday, August 31, 2005 1:43 AM > To: Bob O'Hara (boohara) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Expanded discussion on regulatory certification=20 >=20 > Bob, >=20 > There's an atheros driver too that has explicit txpower parameters = passed t >o a HAL routine to transmit a packet. Mucking with that parameter would = make i >t non-compliant with the regulations.=20 >=20 > Dan. >=20 > On Tue, 30 Aug 2005 22:40:32 PDT you wrote > > Dan, > >=20 > > If I understand the driver that you reference, it has a firmware=20 > >component th at is created by Cisco embedded within it (cribbed by=20 > >reverse engineering the Cisco driver and extracting the binary that = is=20 > >downloaded to the microcoded pr ocessor on the card). It is this=20 > >portion of the driver that controls any port ion of the radio that = can=20 > >affect compliance with regulations. The portion of the driver that = is=20 > >not developed by Cisco does not have access to the portions of the=20 > >802.11 card that can change its operation in a way that would make it = non-co >mpliant with the regulations. > >=20 > > I am actually leaning in the direction that this an(4) driver would=20 > >not cause the FCC to fine anyone that might use it, because it=20 > >encompasses the Cisco mi crocode and might not be seen by the FCC as = an=20 > >unauthorized modification. The FCC might disagree with me, though,=20 > >and might require convincing to see thing s in this light. > >=20 > > I can also see an entirely reasonable interpretation of the=20 > >regulations that would say this is an unauthorized modification. > >=20 > > -Bob > > =20 > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com] > > Sent: Tuesday, August 30, 2005 8:13 PM > > To: Bob O'Hara (boohara) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Expanded discussion on regulatory = certification > >=20 > > Bob, > >=20 > > I'll get back to you on the additional regulatory citations you've > > added-- they are numerous and require some reading and analysis-- = but=20 > > I have an additional couple questions for you. > >=20 > > After I loaded freebsd on my laptop I got a driver to control a=20 > > Cisco Aironet card. It was not written by a Cisco employee. I can=20 > > modify this driver to my heart's content and continue to use my=20 > > modified driver to control that card. > >=20 > > Is it your contention that a Cisco Aironet card plugged into my=20 > > laptop loses its FCC certification? If so, is it also your = contention=20 > that the FCC will fine anyone who plugs a Cisco Aironet card into a=20 > > computer running freebsd with the an(4) driver? > >=20 > > Dan. > >=20 > > On Tue, 30 Aug 2005 13:54:40 PDT you wrote > > > Dan, > > >=20 > > > Your example of loading a different OS onto a PC (which is an=20 > > > unintentional > > r > > >adiator in FCC terms) has little to do with the issue of loading = code=20 > > >that h > >as > > > control of radio parameters, such as transmit power, frequency of=20 > > > operation > >, > > >and spectral shape of the transmitted waveform, onto an AP/WTP = (which=20 > > >the FC > >C > > >classes as an intentional radiator). The OS or other programs=20 > > >running on a > >PC > > > will have little influence over the RF emissions of that device. =20 > > > Sure, cer > >ta > > >in code loops can be created to sing a song on a nearby radio. = But,=20 > > >this is > > s > > >till within the requirements under which the PC was originally=20 > > >certified. D > >ow > > >nloading code to an AP/WTP that, for example, increases the power=20 > > >output on > >a > > >channel adjacent to the edge of a band, can cause the device to = emit=20 > > >a signa > >l > > >that is above that allowed by its certification, causing illegal=20 > > >interferenc > >e > > >in the adjacent band. > > >=20 > > > The difference is very important. It is also very important that=20 > > > this disc > >us > > >sion continue in this forum, as there are very few, if any IETF=20 > > >documents th > >at > > > directly affect whether a device is legal to operate under=20 > > > governmental emi > >ss > > >ions regulations. This might be the first time that the IETF has = had=20 > > >to con > >si > > >der this issue. I believe that many here do not yet understand the = > > >importan > >ce > > > of the issue. > > >=20 > > > But, back to our discussion. > > >=20 > > > You say that it is possible to download code to an AP/WTP that=20 > > > "would retai > >n > > >its certification". This is where there is a fundamental point on=20 > > >which we > >di > > >sagree. I do agree with you that it is possible to download code=20 > > >from a thi > >rd > > > party onto an AP that would continue to have the AP operate in a=20 > > > compliant > >ma > > >nner. But, this is entirely different from that same AP with the=20 > > >third part > >y > > >code running on it maintaining its certification. > > >=20 > > > The certification "belongs" to the manufacturer of the device that = > > > obtained > > i > > >t. It is not transferable or modifiable by anyone else, without=20 > > >express aut > >ho > > >rization of the manufacturer. Downloading code that causes access = to=20 > > >the re > >gi > > >sters of a chip, for example, that has control of the RF = transmission=20 > > >charac > >te > > >ristics of the certified device is modifying the device. > > >=20 > > > Here are additional citations from the regulations governing the=20 > > > certificat > >io > > >n of radio frequency equipment in the United States, supporting = this=20 > > >positio > >n. > > >=20 > > > 47CFR2.909 states the following: > > >=20 > > > The following parties are responsible for the compliance of radio=20 > > > frequency > > e > > >quipment with the applicable standards: > > > (a) In the case of equipment which requires the issuance by the=20 > > >Commission > >of > > > a grant of equipment authorization, the party to whom that grant = of=20 > > > authori > >za > > >tion is issued (the grantee) If the radio frequency equipment is=20 > > >modified by > > a > > >ny party other than the grantee and that party is not working under = > > >the auth > >or > > >ization of the grantee pursuant to =A7 2.929(b), the party = performing=20 > > >the modif > >ic > > >ation is responsible for compliance of the product with the=20 > > >applicable admin > >is > > >trative and technical provisions in this chapter. > > >=20 > > > 47CFR2.909 (d) states the following: > > > (d) If, because of modifications performed subsequent to=20 > > > authorization, a n > >ew > > > party becomes responsible for ensuring that a product complies = with=20 > > > the tec > >hn > > >ical standards and the new party does not obtain a new equipment=20 > > >authorizati > >on > > >, the equipment shall be labelled, following the specifications in = =A7=20 > > >2.925(d) > >, > > >with the following: ''This product has been modified by [insert = name,=20 > > >addres > >s > > >and telephone number of the party performing the modifications].'' > > >=20 > > > 47CFR2.929 states this, as well: > > > =A7 2.929 Nonassignability of an equipment authorization. > > > (a) An equipment authorization issued by the Commission may not be = > > > assigned > >, > > >exchanged or in any other way transferred to a second party. > > >=20 > > > So, for the example well below in this thread, either the third=20 > > > party WTP c > >od > > >e developer, the AC vendor that performs the unauthorized (by the=20 > > >original e > >qu > > >ipment manufacturer) download to the WTP, or possibly the customer=20 > > >that ente > >re > > >d the command to perform the download is now the party responsible=20 > > >for the c > >er > > >tification/authorization of the WTP, not the original = manufacturer. =20 > > >At a m > >in > > >imum, 47CFR2.909 (d) will require someone to physically access each = > > >modified > > W > > >TP to affix a sticker. Even without actually certifying the = modified=20 > > >WTP, t > >he > > > device is now the responsibility of someone other than the = original=20 > > > manufac > >tu > > >rer to ensure that it meets the regulatory requirements. > > >=20 > > > Because our discussion touched on the possibility that the radio=20 > > > portion of > > a > > > modified WTP might be "identical" or use "identical code" to that=20 > > > used by t > >he > > > original manufacturer of the WTP, the following definition is=20 > > > provided by t > >he > > > FCC 47CFR2.908: > > >=20 > > > 2.908 Identical defined. > > > As used in this subpart, the term identical means identical within = > > > the vari > >at > > >ion that can be expected to arise as a result of quantity = production=20 > > >techniq > >ue > > >s. > > >=20 > > > This definition does not encompass a third party changing the code = > > > operatin > >g > > >the device. > > >=20 > > > I would be very interested to understand how these regulatory=20 > > > requirements > >ca > > >n be integrated with your positions, below. > > >=20 > > > -Bob > > > =20 > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Wednesday, August 24, 2005 11:00 AM > > > To: Bob O'Hara (boohara) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > certification > > >=20 > > > Bob, > > >=20 > > > You're absolutely right. Diversion to ad hominem attacks would = not=20 > > > serve the needs of this group. And it's great that no one has=20 > > > resorted to ad hominem attacks! > > >=20 > > > In your company A-D example you have moved the goal posts. = Before=20 > > > you had stated that merely running someone else's code on an AP=20 > > > required recertification. Now you're asking whether an AP can = remain=20 > > > certified "regardless of what code [company B] might download to=20 > > > [Company D's] WTP". Well that's a different question altogether. > > >=20 > > > I believe it would be possible to download an image onto an AP=20 > > > that could make it uncompliant (it could, for example, make the AP = > > > broadcast outside legal limits) and it wouldn't matter whether the = > > > company that created the downloaded image is the same as the = company=20 > > > that certified the AP in the same place. I also believe that it is = > > > possible for a company to download an image onto another company's = > > AP and that AP would retain it's certification. > > >=20 > > > So to answer your quesiton, that depends on what kind of image=20 > > > Cisco downloaded on a Trapeze AP. You could do it right or you = could=20 > > > do it wrong. But the act of downloading the image does not void = the=20 > > > certification of the AP as you have been asserting here all along. > > >=20 > > > My laptop is FCC certified. I don't know how it got certified. I = > > > do know that it was running Windows XP when I pulled it out of the = box. > > > I hate Windows XP and immediately installled FreeBSD on it. I = don't=20 > > > believe my laptop is now in violation of FCC regulations nor do I=20 > > > feel it is necessary to get a different sticker on the bottom of = my=20 > > > laptop. I am also unaware of the FCC going after anyone who has=20 > > > installed an operating system on a computer that was different = than=20 > > > one it was shipped with. > > >=20 > > > You have been unable to demonstrate how image download voids an=20 > > > AP's certification and the snippets of FCC regulations you = supplied=20 > > > did not say anything on that subject. Similarly I have been unable = > > > to demonstrate that image download will not void an AP's = certification. > > > So to answer your last question, yes, we disagree. Unless you can=20 > > > come up with an FCC ruling that refers to the issue at hand and=20 > > > unambiguously states it voids an AP's certification then I think = we=20 > > > should just let this thread die a well-deserved death right here. > > >=20 > > > Dan. > > >=20 > > > On Mon, 22 Aug 2005 16:15:28 PDT you wrote > > > > Dan, > > > >=20 > > > > Diversion to ad hominem attacks does not serve the needs of this = > > > > discussion or of this group. > > > >=20 > > > > If, as you say, there are APs out there today that have been=20 > > > > certified with code from the AP vendor that are now running code = > > > > from a third party (where the AP has not been recertified to run = > > > > with that code), I have to assume that you have personal = knowledge=20 > > > > of these implementations. If you would, please provide a list = (or=20 > > > > at least one > > > > example) that might be provided to the FCC as an example for = them=20 > > > > to resolve the question directly. > > > >=20 > > > > As I said, the code from the ART program used to certify our APs = > > > > and the parameters under which those APs are certified are = running=20 > > > > in the shipping AP under our controller. I am not sure which = part=20 > > > > of that statement is unclear. The fact that this code is = further=20 > > > > integrated into a larger program that performs a number of=20 > > > > functions that do not impact the radio or its RF characteristics = > > > > is irrelevant to the certification. Even if such a larger = program=20 > > > > were to modify the RF characteristics, it is possible, with=20 > > > > limitations, for the manufacturer of the AP to file a = "permissive=20 > > > > change" with the FCC to maintain its certification. The only=20 > > > > reason we might be able to do this is because we are the = manufacturer o >f the AP and have previously certified the AP. > > > > An arbitrary third party is not allowed this freedom. > > > >=20 > > > > Let me be clearer also about the example and question from my = last=20 > > > > email. > > > >=20 > > > > Let's say Company A is a developer of AP/WTP download modules. > > > > Company B is an AC vendor that has licensed a module from = Company=20 > > > > A for download through SLAPP. > > > > Company C is the customer that has deployed the WLAN. > > > > Company D is the manufacturer of the AP/WTP that has certified = the=20 > > > > device running their own code. > > > >=20 > > > > Your answer to my question below indicates to me that, if Cisco=20 > > > > were Company B and Trapeze were Company D, you believe that the=20 > > > > Trapeze certification of the AP/WTP would stand, regardless of=20 > > > > what code Cisco might download to the Trapeze AP/WTP. Am I=20 > > > > correct in my interpretation of your answer? > > > >=20 > > > > If I am correct in interpreting your answer to the question, I=20 > > > > disagree with your answer. I would find it wildly unlikely that = > > > > Trapeze would stand up and claim that their AP/WTP hardware is=20 > > > > fully compliant with the regulations when that hardware is = running=20 > > > > any code but their own. I am almost certain (though I don't = speak=20 > > > > for the company on this) that Cisco would not agree that our AP=20 > > > > would always operate within the regulations when running any = code than=20 >that supplied by Cisco. > > > >=20 > > > > Perhaps you disagree? > > > >=20 > > > > -Bob > > > > =20 > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > Sent: Monday, August 22, 2005 1:59 PM > > > > To: Bob O'Hara (boohara) > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > > certification > > > >=20 > > > > Bob, > > > >=20 > > > > There's nothing cute about it. You're spreading FUD-- Fear = (the=20 > > > > FCC will fine me!), Uncertainty (they don't recertify but I = think=20 > > > > we might have to), and Doubt (he was wearing his "technical = advisor hat >" > > > > and that must mean something). In fact, it's the opposite of = cute;=20 > > > > it's a big, smelly, steaming pile o' FUD. > > > >=20 > > > > If this issue is, as you say, as real as the fines the FCC = will=20 > > > > levy then there is no issue. This is being done today and the = FCC=20 > > > > is not fining anyone. > > > >=20 > > > > I was not implying any slight of hand. The thing is, you = market=20 > > > > code that did not operate the AP when it was certified and you = do=20 > > > > not recertify when you install that code on the AP. And nor = should=20 > > > > you because, as I've been saying all along, it is not necessary = to=20 > > > > recertify an AP simply because code that was not part of the=20 > > > > original certification is downloaded onto it. > > > >=20 > > > > To answer your question, company D had to have certified their = > > > > WTP prior to marketing it (they could've ran=20 > > > > ART_V48_build_13_alpha to get their certification, for = instance).=20 > > > > Since they are the company responsible for certification they=20 > > > > would supply information as may be requested concerning the=20 > > > > operation of the device to the Commission or its = representatives. > > > >=20 > > > > Dan. > > > >=20 > > > > On Mon, 22 Aug 2005 11:53:35 PDT you wrote > > > > > Dan, > > > > >=20 > > > > > The issue is not, as you put it, "just an unfortunate bunch of = FUD". > > > > > That is a cute attempt at diverting people from the issue. = But=20 > > > > > ultimately, it is futile. The folks in the CAPWAP group can=20 > > > > > research and address this issue now, or surely those that=20 > > > > > implement and deploy > > > > a > > > > > CAPWAP protocol in the future will have to address it in the = future.=20 >=20 > > > > >=20 > > > > > The requirement for certification of RF devices is not going = to=20 > > > > > go > > > > away. > > > > > Let me quote a few bits from the FCC regulations for = unlicensed > > > > devices: > > > > >=20 > > > > > Section 15.15 General technical requirements. > > > > > (b) An intentional or unintentional radiator must be = constructed=20 > > > > > such that the adjustments of any control that is readily=20 > > > > > accessible by or intended to be accessible to the user will = not=20 > > > > > cause operation of the device in violation of the regulations. > > > > >=20 > > > > > Section 15.29 Inspection by the Commission. > > > > > (c) The party responsible for the compliance of any device=20 > > > > > subject to this Part shall promptly furnish to the Commission = or=20 > > > > > its representatives such information as may be requested=20 > > > > > concerning the operation of the device, including a copy of = any=20 > > > > > measurements made for obtaining an equipment authorization or=20 > > > > > demonstrating compliance with the regulations. > > > > >=20 > > > > > Section 15.201 Equipment authorization requirement. > > > > > (b) Except as otherwise exempted in paragraph (c) of this=20 > > > > > Section and > > > > in > > > > > Section 15.23 of this > > > > > Part, all intentional radiators operating under the provisions = > > > > > of this Part shall be certificated by the Commission pursuant = to=20 > > > > > the procedures in Subpart J of Part 2 of this Chapter prior to = > > > > > marketing. > > > > >=20 > > > > > Who would you say is "the party responsible for the = compliance"=20 > > > > > of a device that has been downloaded with third party code to=20 > > > > > operate the radio in an AP under the SLAPP proposal? If, for=20 > > > > > example, Company A were to distribute code written by Company = B=20 > > > > > to Company C to download using SLAPP onto a WTP from Company = D,=20 > > > > > who is responsible for ensuring that the device is operating=20 > > > > > within the regulations? In this > > > > scenario, > > > > > who is responsible for furnishing to the Commission a copy of=20 > > > > > the measurements made for obtaining equipment authorization? > > > > >=20 > > > > > To address your other point, yes, we certify using the ART = test > > > > program. > > > > > We also incorporate the identical parameters and code required = > > > > > to maintain that certification in our operational code for the = APs. > > > > There > > > > > is no sleight of hand here, as it appears you are implying. > > > > >=20 > > > > > The issue of certification when an unauthorized third party=20 > > > > > downloads code onto a device incorporating a radio is real, as = > > > > > will be the fines levied by the FCC upon that third party (or=20 > > > > > perhaps the third party's customer, or both) for operating an = RF=20 > > > > > emitting device (an > > > > "intentional > > > > > radiator" in FCC terms) without the proper certifications. > > > > >=20 > > > > > You can try telling everyone to "ignore the man behind the = curtain" > > > > and > > > > > believe that you are living in Oz. But, in actuality, you are > > > > dreaming. > > > > >=20 > > > > > -Bob > > > > > =20 > > > > > -----Original Message----- > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > Sent: Wednesday, August 17, 2005 4:24 PM > > > > > To: Bob O'Hara (boohara) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory=20 > > > > > certification > > > > >=20 > > > > > Bob, > > > > >=20 > > > > > After looking at an FCC test report for the certification of = > > > > > Airespace's AS1250 it appears that you got certification not = by=20 > > > > > running your operational AP code but by running=20 > > > > > "ART_V48_build_13_alpha". So you received certification for = your=20 > > > > > APs by running code on them that is not your's and is not what = a=20 > > > > > customer runs on them. Your own operational image is loaded = onto=20 > > > > > these APs prior to shipping yet you do not recertify them with > > > > this > > > > > new code load. > > > > >=20 > > > > > So this entire issue about recertification being necessary = is=20 > > > > > just > > > > an > > > > > unfortunate bunch of FUD. > > > > >=20 > > > > > Dan. > > > > >=20 > > > > > On Thu, 04 Aug 2005 02:07:39 PDT you wrote > > > > > > <802.11 Technical advisor to CAPWAP hat> Yes, it is my=20 > > > > > > assertion that recertification is necessary. Just > > > > > because > > > > > > you suggest it may not be true, does not make it less true. > > > > > > > > > > > >=20 > > > > > > And actually, having to put another sticker on an AP has=20 > > > > > > everything > > > > to > > > > > > do with CAPWAP. Using a protocol that requires such manual > > > > operations > > > > > > at every CAPWAP AP (and not even manual operations across = the > > > > network, > > > > > > but manual operations at the top of a ladder with your head=20 > > > > > > poked > > > > into > > > > > > the hole made by moving the ceiling tile aside) hardly makes = > > > > > > for > > > > ease > > > > > of > > > > > > management or configuration consistency. It seems that a=20 > > > > > > protocol > > > > > that > > > > > > requires such manual operations does not meet Objective = 5.1.2,=20 > > > > > > configuration consistency, since the protocol cannot allow = an=20 > > > > > > AC to determine if it is legal to operate a third party WTP=20 > > > > > > after a > > > > software > > > > > > download has taken place. In the US, at least, it is not=20 > > > > > > legal to operate a Part 15.247 device (say, all 802.11b/g = APs)=20 > > > > > > without the appropriate FCCID. I am certain this is true in = > > > > > > many other > > > > regulatory > > > > > > domains, as well. > > > > > >=20 > > > > > >=20 > > > > > > -Bob > > > > > > =20 > > > > > > -----Original Message----- > > > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > > > Sent: Wednesday, August 03, 2005 3:29 AM > > > > > > To: Bob O'Hara (boohara) > > > > > > Cc: capwap@frascone.com > > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > > > certification > > > > > >=20 > > > > > > I was that presenter and I don't think that = recertification=20 > > > > > > is necessary, but again, that's outside my job function. > > > > > >=20 > > > > > > It may be your assertion that recertification is necessary = > > > > > > but > > > > > that's > > > > > > just your assertion, it doesn't mean it's true. And=20 > > > > > > furthermore > > > > > whether > > > > > > someone has to put a sticker on an AP has nothing to do with = CAPWAP >. > > > >=20 > > > > > >=20 > > > > > > Dan. > > > > > >=20 > > > > > > On Wed, 03 Aug 2005 03:04:21 PDT you wrote > > > > > > > At the working group meeting, I asked the presenter for=20 > > > > > > SLAPP > > > > about > > > > > > the > > > > > > > impact of downloading code into third party WTPs that have > > > > received > > > > > > > regulatory certification. At that time, the presenter = said=20 > > > > > > > that > > > > he > > > > > > was > > > > > > > not expert in that area, but suspected that = recertification=20 > > > > > > > of the device would be necessary with the newly downloaded = > > > > > > > code. I would > > > > > > like > > > > > > > to discuss this further on the list. =20 > > > > > > >=20 > > > > > > > It is my assertion that all regulatory agencies that = require=20 > > > > > > > certification of WTPs for operation in their jurisdiction=20 > > > > > > > will > > > > > require > > > > > > > that WTPs that receive code and use it for operation, when = > > > > > > > that > > > > code > > > > > > is > > > > > > > not from the entity that received the original = certification=20 > > > > > > > for > > > > the > > > > > > > device, will require a new certification of that device = with=20 > > > > > > > the > > > > > new, > > > > > > > third party code. > > > > > > >=20 > > > > > > > In addition, nearly all regulatory agencies, certainly = those=20 > > > > > > > in > > > > > North > > > > > > > America, Europe, Asia, and the Middle East, require an=20 > > > > > > > external indication of the certification, usually a = sticker=20 > > > > > > > with an > > > > > identifying > > > > > > > string. I also assert that downloading new code to a = third=20 > > > > > > > party > > > > > WTP > > > > > > > will require that all WTPs that have received that code = must=20 > > > > > > > now > > > > > also > > > > > > be > > > > > > > physically accessed to have a new sticker affixed. > > > > > > >=20 > > > > > > > It is not sufficient for an AC vendor to simply develop = code=20 > > > > > > > ports > > > > > for > > > > > > > each silicon vendor and WTP reference design from those=20 > > > > > > > silicon > > > > > > vendors. > > > > > > > The AC vendors must now obtain regulatory certification = for=20 > > > > > > > every > > > > > WTP > > > > > > > manufactured. Similarly, each WTP vendor must now obtain > > > > regulatory > > > > > > > certification with every AC vendor. > > > > > > >=20 > > > > > > > This will be a significant additional cost for all AC and=20 > > > > > > > WTP > > > > > vendors. > > > > > > > Where current devices need to be certified once for each > > > > regulatory > > > > > > > domain, SLAPP will require that each device is certified=20 > > > > > > > several > > > > > times > > > > > > > for each regulatory domain. The cost of regulatory=20 > > > > > > > certification > > > > > for > > > > > > an > > > > > > > AC vendor is now multiplied by the number of WTPs that is > > > > supports. > > > > > > > Similarly, the cost of certification for a WTP vendor is > > > > multiplied > > > > > by > > > > > > > the number of ACs that are supported. Even sharing the = cost=20 > > > > > > > of certification between AC and WTP vendor only cuts this=20 > > > > > > > cost in > > > > half. > > > > > > It > > > > > > > is still dramatically larger than with any other proposal. > > > > > > >=20 > > > > > > > This is a very important issue. With SLAPP, it is no = longer > > > > > > sufficient > > > > > > > to state support for the ultimate CAPWAP protocol to be > > > > > interoperable. > > > > > > > It is now necessary that there be a specific business > > > > relationships > > > > > > > between AC and WTP vendors or a list of "compatible" = vendors=20 > > > > > > > and > > > > > model > > > > > > > numbers. > > > > > > >=20 > > > > > > > I believe that this also significantly raises the barriers = > > > > > > > to > > > > entry > > > > > > for > > > > > > > AC and WTP vendors, since the cost of market entry is=20 > > > > > > > associated > > > > > with > > > > > > > the costs of regulatory certification with a potentially=20 > > > > > > > large > > > > > number > > > > > > of > > > > > > > ACs and WTPs. As the number of ACs and WTPs increase, = this=20 > > > > > > > cost > > > > > also > > > > > > > increases. The result is likely to be an entrenchment of=20 > > > > > > > the > > > > early > > > > > > > entrants into this market and the exclusion of new = participants. > > > > > > >=20 > > > > > > > So, my final assertion is that adoption of the SLAPP model = > > > > > > > for > > > > > CAPWAP > > > > > > > would have exactly the opposite effect that is desired = from=20 > > > > > > > standardization, which is lower costs, greater = competition,=20 > > > > > > > and > > > > > widely > > > > > > > interoperable products. > > > > > > >=20 > > > > > > > -Bob > > > > > > >=20 > > > > > > > Bob O'Hara > > > > > > > Cisco Systems - WNBU > > > > > > >=20 > > > > > > > Phone: +1 408 853 5513 > > > > > > > Mobile: +1 408 218 4025 > > > > > > > =20 > > > > > > > _______________________________________________ > > > > > > > Capwap mailing list > > > > > > > Capwap@frascone.com > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > >=20 > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > >=20 > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > >=20 > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > >=20 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 02 19:29:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBKy6-00036k-Lw for capwap-archive@megatron.ietf.org; Fri, 02 Sep 2005 19:29:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18092 for ; Fri, 2 Sep 2005 19:29:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B4E1220569; Fri, 2 Sep 2005 19:29:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3453020278; Fri, 2 Sep 2005 19:29:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC5F820278 for ; Fri, 2 Sep 2005 19:28:31 -0400 (EDT) Received: from smtpout1.bayarea.net (smtpout1.bayarea.net [209.128.95.10]) by mail.frascone.com (Postfix) with ESMTP id BE95E201F6 for ; Fri, 2 Sep 2005 19:28:29 -0400 (EDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j82NSYBT029770; Fri, 2 Sep 2005 16:28:34 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j82NSSQf014057; Fri, 2 Sep 2005 16:28:28 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j82NSRQJ014049; Fri, 2 Sep 2005 16:28:28 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Bob O'Hara (boohara)" Cc: capwap@frascone.com Subject: RE: [Capwap] Expanded discussion on regulatory certification In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC86030D@xmb-sjc-237.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 2 Sep 2005 16:28:27 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) HI, HI, So it seems to me the issue is the following.... Should the CAPWAP protocol be restricted in what it can do by the manufacturer of the equipment (in this case the WTP), or should it allow the user (owner) of the equipment to decide. Note that it is an agreed requirement that CAPWAP has the security features so that operations can be restricted to authorized users. This, essentially the same, issue comes up all the time in network/device management. That is, should some how the management protocol restrict the configuration or action to "proper" values or actions. Where "proper" might mean "so it will do some useful work", "so it will not self destruct", "so it will not cause harm to others", etc. RFCs now have "a security considerations" section so to bring to the light deployment issues. So, in the end, I believe it is up to the owner of equipment to make proper choices (and be responsible for those choices), and not up to protocol developers to decide what is right or wrong. Or to put it another way... If the protocol makes it "darn near impossible" to do something, but over time a legitimate reason comes up, the work around of the protocol prohibitation is usually pretty expensive. Regards, /david t. perkins _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Sep 03 02:00:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBR4V-0006oo-2l for capwap-archive@megatron.ietf.org; Sat, 03 Sep 2005 02:00:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02898 for ; Sat, 3 Sep 2005 02:00:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CF962065C; Sat, 3 Sep 2005 02:00:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1997205BC; Sat, 3 Sep 2005 02:00:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 229D420624 for ; Sat, 3 Sep 2005 01:59:19 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 3689F205BC for ; Sat, 3 Sep 2005 01:59:16 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j835qkk1038998; Fri, 2 Sep 2005 22:52:46 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509030552.j835qkk1038998@homebrew.trpz.com> To: "Bob O'Hara (boohara)" Cc: capwap@frascone.com Subject: Re: [Capwap] Expanded discussion on regulatory certification In-Reply-To: Your message of "Fri, 02 Sep 2005 13:15:10 PDT." <17B8C6DE4E228348B4939BDA6B05A9DC86030D@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38996.1125726765.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 02 Sep 2005 22:52:46 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Bob, On Fri, 02 Sep 2005 13:15:10 PDT you wrote [snip] > > Both the SLAPP and LWAPP protocol proposals include the ability to download c >ode to an AP/WTP. The difference between the two is that CAPWAP requires an a >uthentication signature must be validated before a download can be used, while > SLAPP has no such mechanism and specifically allows download of code from sou >rces other than the manufacturer or an authorized delegate of the manufacturer >. This is a significant difference between the two protocols and needs to be >considered when evaluating the protocols during this phase of selecting the ba >sis for CAPWAP standardization. "Both the SLAPP and LWAPP protocol proposals.... The difference between the two is that CAPWAP requires an authentication signature must be validated before a download can be used, while SLAPP has no such mechanism...." LWAPP = CAPWAP? I think you're getting a little excited here Bob. Either that or you know something that has not been made public yet. What you don't know is how SLAPP works. Please go read the spec. There is an authentication step PRIOR to the AC and WTP deciding whether to proceed to the full-fledged control and provisioning protocol or to do image download. > Going back to one of my first statements on this topic and to bring this arou >nd again to why this discussion is important to the working group while evalua >ting protocols, independent implementations of LWAPP can be built from the pro >tocol specification, alone. That same statement cannot be made about SLAPP. Wrong! SLAPP includes a complete provisioning and control protocol. Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Sep 03 09:31:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBY6w-0006Tt-EZ for capwap-archive@megatron.ietf.org; Sat, 03 Sep 2005 09:31:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04951 for ; Sat, 3 Sep 2005 09:31:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1D5C20658; Sat, 3 Sep 2005 09:31:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 488BE205BC; Sat, 3 Sep 2005 09:31:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB3A120624 for ; Sat, 3 Sep 2005 09:30:17 -0400 (EDT) Received: from oz.twisted.net (oz.twisted.net [69.211.34.241]) by mail.frascone.com (Postfix) with ESMTP id E4626205BC for ; Sat, 3 Sep 2005 09:30:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by oz.twisted.net (Postfix) with ESMTP id 1373E599B97 for ; Sat, 3 Sep 2005 08:39:29 -0500 (CDT) Received: from oz.twisted.net ([127.0.0.1]) by localhost (oz.twisted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17378-04 for ; Sat, 3 Sep 2005 08:39:28 -0500 (CDT) Received: from noodle (sindrome.twisted.net [172.16.0.5]) by oz.twisted.net (Postfix) with ESMTP id 47E7E59904C for ; Sat, 3 Sep 2005 08:39:21 -0500 (CDT) Reply-To: From: "Troy Dixler" To: Subject: RE: [Capwap] Expanded discussion on regulatory certification MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcWwTkKGMxBLWBEeRTm3bw1m5SNNeAAO4RUg In-Reply-To: <200509030552.j835qkk1038998@homebrew.trpz.com> Message-Id: <20050903133921.47E7E59904C@oz.twisted.net> X-Virus-Scanned: by amavisd-new at twisted.net X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sat, 3 Sep 2005 08:28:56 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Guys, I've been watching the argument on this thread and feel that it's time to make a statement as a working group member. There are two very separate arguments going on here. One is related to IPR claims and the other around image download and FCC violations. I am not making this comment around the image download portion but believe it's essential to discuss the IPR issue. I've seen the IPR game getting out of hand within the IETF for way too long. There are way too many drafts that are coming into the IETF standards process claiming IPR. The purpose for the CAPWAP working group is to create an OPEN standard that all vendors can implement and show interoperability. Regardless of the image download argument, before I'll stand up and back the LWAPP or SLAPP contribution, I want Cisco as well as Trapeze to remove any notion of owing IPR where they can go after other vendors that implement an IETF standard. That simply does not wash. If the IPR comment stands then we as a working group must engineer around any/all requirements and come up with a standard that does not allow one vendor to have that type of power. I do not buy into any comments such as "we would never do it" or "we want to contribute to this moving forward" etc. If that is the case, drop the IPR claim and then we can go back to considering what protocol would best represent the basis for CAPWAP. The notion of trying to move on from this topic and even consider using a protocol that has this type of IPR claim is ridiculous (IMHO). I want an IPR free protocol standard out of this group. So there are two questions. Will both the main authors of each of the specs remove any/all IPR claims for consideration of being in the spec? It's a simple question of yes or no. Please do not present a long reply without answering it as a binary decision. -Troy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Dan Harkins > Sent: Saturday, September 03, 2005 12:53 AM > To: Bob O'Hara (boohara) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Expanded discussion on regulatory certification > > Bob, > > On Fri, 02 Sep 2005 13:15:10 PDT you wrote > [snip] > > > > Both the SLAPP and LWAPP protocol proposals include the ability to > download c > >ode to an AP/WTP. The difference between the two is that CAPWAP requires > an a > >uthentication signature must be validated before a download can be used, > while > > SLAPP has no such mechanism and specifically allows download of code > from sou > >rces other than the manufacturer or an authorized delegate of the > manufacturer > >. This is a significant difference between the two protocols and needs > to be > >considered when evaluating the protocols during this phase of selecting > the ba > >sis for CAPWAP standardization. > > "Both the SLAPP and LWAPP protocol proposals.... The difference between > the > two is that CAPWAP requires an authentication signature must be validated > before a download can be used, while SLAPP has no such mechanism...." > > LWAPP = CAPWAP? I think you're getting a little excited here Bob. Either > that or you know something that has not been made public yet. > > What you don't know is how SLAPP works. Please go read the spec. There is > an authentication step PRIOR to the AC and WTP deciding whether to proceed > to the full-fledged control and provisioning protocol or to do image > download. > > > Going back to one of my first statements on this topic and to bring this > arou > >nd again to why this discussion is important to the working group while > evalua > >ting protocols, independent implementations of LWAPP can be built from > the pro > >tocol specification, alone. That same statement cannot be made about > SLAPP. > > Wrong! SLAPP includes a complete provisioning and control protocol. > > Dan. > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Sep 03 12:54:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBbHP-00046Z-AR for capwap-archive@megatron.ietf.org; Sat, 03 Sep 2005 12:54:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14516 for ; Sat, 3 Sep 2005 12:54:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6545820661; Sat, 3 Sep 2005 12:54:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 937E8204E7; Sat, 3 Sep 2005 12:54:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 04484204E7 for ; Sat, 3 Sep 2005 12:53:23 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id CFBCF204E6 for ; Sat, 3 Sep 2005 12:53:21 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j83GkuUB040800; Sat, 3 Sep 2005 09:47:01 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509031647.j83GkuUB040800@homebrew.trpz.com> To: troy@twisted.net Cc: capwap@frascone.com In-Reply-To: Your message of "Sat, 03 Sep 2005 08:28:56 CDT." <20050903133921.47E7E59904C@oz.twisted.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40798.1125766016.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] this is not the thread on expanded discussion on regulatory certification which has now officially ended Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sat, 03 Sep 2005 09:46:56 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Troy, There is no IPR claim on SLAPP to remove. Dan. On Sat, 03 Sep 2005 08:28:56 CDT you wrote > Guys, > > I've been watching the argument on this thread and feel that it's time to > make a statement as a working group member. There are two very separate > arguments going on here. One is related to IPR claims and the other around > image download and FCC violations. I am not making this comment around the > image download portion but believe it's essential to discuss the IPR issue. > > I've seen the IPR game getting out of hand within the IETF for way too long. > There are way too many drafts that are coming into the IETF standards > process claiming IPR. > > The purpose for the CAPWAP working group is to create an OPEN standard that > all vendors can implement and show interoperability. Regardless of the > image download argument, before I'll stand up and back the LWAPP or SLAPP > contribution, I want Cisco as well as Trapeze to remove any notion of owing > IPR where they can go after other vendors that implement an IETF standard. > That simply does not wash. > > If the IPR comment stands then we as a working group must engineer around > any/all requirements and come up with a standard that does not allow one > vendor to have that type of power. > > I do not buy into any comments such as "we would never do it" or "we want to > contribute to this moving forward" etc. If that is the case, drop the IPR > claim and then we can go back to considering what protocol would best > represent the basis for CAPWAP. > > The notion of trying to move on from this topic and even consider using a > protocol that has this type of IPR claim is ridiculous (IMHO). I want an > IPR free protocol standard out of this group. > > So there are two questions. Will both the main authors of each of the specs > remove any/all IPR claims for consideration of being in the spec? It's a > simple question of yes or no. Please do not present a long reply without > answering it as a binary decision. > > -Troy > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Dan Harkins > > Sent: Saturday, September 03, 2005 12:53 AM > > To: Bob O'Hara (boohara) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Expanded discussion on regulatory certification > > > > Bob, > > > > On Fri, 02 Sep 2005 13:15:10 PDT you wrote > > [snip] > > > > > > Both the SLAPP and LWAPP protocol proposals include the ability to > > download c > > >ode to an AP/WTP. The difference between the two is that CAPWAP requires > > an a > > >uthentication signature must be validated before a download can be used, > > while > > > SLAPP has no such mechanism and specifically allows download of code > > from sou > > >rces other than the manufacturer or an authorized delegate of the > > manufacturer > > >. This is a significant difference between the two protocols and needs > > to be > > >considered when evaluating the protocols during this phase of selecting > > the ba > > >sis for CAPWAP standardization. > > > > "Both the SLAPP and LWAPP protocol proposals.... The difference between > > the > > two is that CAPWAP requires an authentication signature must be validated > > before a download can be used, while SLAPP has no such mechanism...." > > > > LWAPP = CAPWAP? I think you're getting a little excited here Bob. Either > > that or you know something that has not been made public yet. > > > > What you don't know is how SLAPP works. Please go read the spec. There is > > an authentication step PRIOR to the AC and WTP deciding whether to proceed > > to the full-fledged control and provisioning protocol or to do image > > download. > > > > > Going back to one of my first statements on this topic and to bring this > > arou > > >nd again to why this discussion is important to the working group while > > evalua > > >ting protocols, independent implementations of LWAPP can be built from > > the pro > > >tocol specification, alone. That same statement cannot be made about > > SLAPP. > > > > Wrong! SLAPP includes a complete provisioning and control protocol. > > > > Dan. > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Sep 03 14:22:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBcf7-0002JI-0F for capwap-archive@megatron.ietf.org; Sat, 03 Sep 2005 14:22:45 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18117 for ; Sat, 3 Sep 2005 14:22:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CB9E20668; Sat, 3 Sep 2005 14:21:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4175A204E7; Sat, 3 Sep 2005 14:21:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 41BF5204EC for ; Sat, 3 Sep 2005 14:20:22 -0400 (EDT) Received: from aruba-mx.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by mail.frascone.com (Postfix) with SMTP id 0DE15204E7 for ; Sat, 3 Sep 2005 14:20:20 -0400 (EDT) Received: from [192.168.1.177] ([24.6.194.144] RDNS failed) by aruba-mx.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Sep 2005 11:20:19 -0700 Message-ID: <4319E95F.3040801@arubanetworks.com> From: Partha Narasimhan User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Harkins Cc: troy@twisted.net, capwap@frascone.com Subject: Re: [Capwap] this is not the thread on expanded discussion on regulatory certification which has now officially ended References: <200509031647.j83GkuUB040800@homebrew.trpz.com> In-Reply-To: <200509031647.j83GkuUB040800@homebrew.trpz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2005 18:20:19.0637 (UTC) FILETIME=[241C6650:01C5B0B4] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sat, 03 Sep 2005 11:20:15 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I concur with Dan regarding IPR and SLAPP. Our goal was to come up with a proposal that re-used existing protocols as much as possible resulting in a simple, yet complete proposal. Thanks partha Dan Harkins wrote: > Troy, > > There is no IPR claim on SLAPP to remove. > > Dan. > >On Sat, 03 Sep 2005 08:28:56 CDT you wrote > > >>Guys, >> >>I've been watching the argument on this thread and feel that it's time to >>make a statement as a working group member. There are two very separate >>arguments going on here. One is related to IPR claims and the other around >>image download and FCC violations. I am not making this comment around the >>image download portion but believe it's essential to discuss the IPR issue. >> >>I've seen the IPR game getting out of hand within the IETF for way too long. >>There are way too many drafts that are coming into the IETF standards >>process claiming IPR. >> >>The purpose for the CAPWAP working group is to create an OPEN standard that >>all vendors can implement and show interoperability. Regardless of the >>image download argument, before I'll stand up and back the LWAPP or SLAPP >>contribution, I want Cisco as well as Trapeze to remove any notion of owing >>IPR where they can go after other vendors that implement an IETF standard. >>That simply does not wash. >> >>If the IPR comment stands then we as a working group must engineer around >>any/all requirements and come up with a standard that does not allow one >>vendor to have that type of power. >> >>I do not buy into any comments such as "we would never do it" or "we want to >>contribute to this moving forward" etc. If that is the case, drop the IPR >>claim and then we can go back to considering what protocol would best >>represent the basis for CAPWAP. >> >>The notion of trying to move on from this topic and even consider using a >>protocol that has this type of IPR claim is ridiculous (IMHO). I want an >>IPR free protocol standard out of this group. >> >>So there are two questions. Will both the main authors of each of the specs >>remove any/all IPR claims for consideration of being in the spec? It's a >>simple question of yes or no. Please do not present a long reply without >>answering it as a binary decision. >> >>-Troy >> >> >> >> >>>-----Original Message----- >>>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>>Behalf Of Dan Harkins >>>Sent: Saturday, September 03, 2005 12:53 AM >>>To: Bob O'Hara (boohara) >>>Cc: capwap@frascone.com >>>Subject: Re: [Capwap] Expanded discussion on regulatory certification >>> >>> Bob, >>> >>>On Fri, 02 Sep 2005 13:15:10 PDT you wrote >>>[snip] >>> >>> >>>>Both the SLAPP and LWAPP protocol proposals include the ability to >>>> >>>> >>>download c >>> >>> >>>>ode to an AP/WTP. The difference between the two is that CAPWAP requires >>>> >>>> >>>an a >>> >>> >>>>uthentication signature must be validated before a download can be used, >>>> >>>> >>>while >>> >>> >>>>SLAPP has no such mechanism and specifically allows download of code >>>> >>>> >>>from sou >>> >>> >>>>rces other than the manufacturer or an authorized delegate of the >>>> >>>> >>>manufacturer >>> >>> >>>>. This is a significant difference between the two protocols and needs >>>> >>>> >>>to be >>> >>> >>>>considered when evaluating the protocols during this phase of selecting >>>> >>>> >>>the ba >>> >>> >>>>sis for CAPWAP standardization. >>>> >>>> >>>"Both the SLAPP and LWAPP protocol proposals.... The difference between >>>the >>>two is that CAPWAP requires an authentication signature must be validated >>>before a download can be used, while SLAPP has no such mechanism...." >>> >>>LWAPP = CAPWAP? I think you're getting a little excited here Bob. Either >>>that or you know something that has not been made public yet. >>> >>>What you don't know is how SLAPP works. Please go read the spec. There is >>>an authentication step PRIOR to the AC and WTP deciding whether to proceed >>>to the full-fledged control and provisioning protocol or to do image >>>download. >>> >>> >>> >>>>Going back to one of my first statements on this topic and to bring this >>>> >>>> >>>arou >>> >>> >>>>nd again to why this discussion is important to the working group while >>>> >>>> >>>evalua >>> >>> >>>>ting protocols, independent implementations of LWAPP can be built from >>>> >>>> >>>the pro >>> >>> >>>>tocol specification, alone. That same statement cannot be made about >>>> >>>> >>>SLAPP. >>> >>>Wrong! SLAPP includes a complete provisioning and control protocol. >>> >>> Dan. >>> >>>_______________________________________________ >>>Capwap mailing list >>>Capwap@frascone.com >>>http://mail.frascone.com/mailman/listinfo/capwap >>> >>> >>_______________________________________________ >>Capwap mailing list >>Capwap@frascone.com >>http://mail.frascone.com/mailman/listinfo/capwap >> >> >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Sep 03 17:07:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBfEH-0004MH-3i for capwap-archive@megatron.ietf.org; Sat, 03 Sep 2005 17:07:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25132 for ; Sat, 3 Sep 2005 17:07:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4173F2066B; Sat, 3 Sep 2005 17:07:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3874D2065C; Sat, 3 Sep 2005 17:07:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 28C4D2065C for ; Sat, 3 Sep 2005 17:06:36 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id 0F6E4204C6 for ; Sat, 3 Sep 2005 17:06:34 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j83L6VsH013214; Sat, 3 Sep 2005 16:06:32 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 3 Sep 2005 23:06:30 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507EE0F2E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Dan Harkins , troy@twisted.net Cc: capwap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IPR issues Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sat, 3 Sep 2005 23:06:28 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) All, I changed the subject line. This is not about FCC certification but about IPR. The question to be asked is: does anyone know if there is any IPR anywhere. According to the NOTE WELL, if anyone who contributes to or participates in this WG, then they MUST disclose if they know about any IPR of the technology being discussed in the WG. Even if it is IPR that they know someone else is holding. And so that includes all submitted technologies. Pls also read RFC 3978 and RFC 3979 Bert > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of Dan Harkins > Sent: Saturday, September 03, 2005 13:47 > To: troy@twisted.net > Cc: capwap@frascone.com > Subject: [Capwap] this is not the thread on expanded discussion on > regulatory certification which has now officially ended > > > Troy, > > There is no IPR claim on SLAPP to remove. > > Dan. > > On Sat, 03 Sep 2005 08:28:56 CDT you wrote > > Guys, > > > > I've been watching the argument on this thread and feel > that it's time to > > make a statement as a working group member. There are two > very separate > > arguments going on here. One is related to IPR claims and > the other around > > image download and FCC violations. I am not making this > comment around the > > image download portion but believe it's essential to > discuss the IPR issue. > > > > I've seen the IPR game getting out of hand within the IETF > for way too long. > > There are way too many drafts that are coming into the IETF > standards > > process claiming IPR. > > > > The purpose for the CAPWAP working group is to create an > OPEN standard that > > all vendors can implement and show interoperability. > Regardless of the > > image download argument, before I'll stand up and back the > LWAPP or SLAPP > > contribution, I want Cisco as well as Trapeze to remove any > notion of owing > > IPR where they can go after other vendors that implement an > IETF standard. > > That simply does not wash. > > > > If the IPR comment stands then we as a working group must > engineer around > > any/all requirements and come up with a standard that does > not allow one > > vendor to have that type of power. > > > > I do not buy into any comments such as "we would never do > it" or "we want to > > contribute to this moving forward" etc. If that is the > case, drop the IPR > > claim and then we can go back to considering what protocol > would best > > represent the basis for CAPWAP. > > > > The notion of trying to move on from this topic and even > consider using a > > protocol that has this type of IPR claim is ridiculous > (IMHO). I want an > > IPR free protocol standard out of this group. > > > > So there are two questions. Will both the main authors of > each of the specs > > remove any/all IPR claims for consideration of being in the > spec? It's a > > simple question of yes or no. Please do not present a long > reply without > > answering it as a binary decision. > > > > -Troy > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On > > > Behalf Of Dan Harkins > > > Sent: Saturday, September 03, 2005 12:53 AM > > > To: Bob O'Hara (boohara) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Expanded discussion on regulatory > certification > > > > > > Bob, > > > > > > On Fri, 02 Sep 2005 13:15:10 PDT you wrote > > > [snip] > > > > > > > > Both the SLAPP and LWAPP protocol proposals include the > ability to > > > download c > > > >ode to an AP/WTP. The difference between the two is > that CAPWAP requires > > > an a > > > >uthentication signature must be validated before a > download can be used, > > > while > > > > SLAPP has no such mechanism and specifically allows > download of code > > > from sou > > > >rces other than the manufacturer or an authorized delegate of the > > > manufacturer > > > >. This is a significant difference between the two > protocols and needs > > > to be > > > >considered when evaluating the protocols during this > phase of selecting > > > the ba > > > >sis for CAPWAP standardization. > > > > > > "Both the SLAPP and LWAPP protocol proposals.... The > difference between > > > the > > > two is that CAPWAP requires an authentication signature > must be validated > > > before a download can be used, while SLAPP has no such > mechanism...." > > > > > > LWAPP = CAPWAP? I think you're getting a little excited > here Bob. Either > > > that or you know something that has not been made public yet. > > > > > > What you don't know is how SLAPP works. Please go read > the spec. There is > > > an authentication step PRIOR to the AC and WTP deciding > whether to proceed > > > to the full-fledged control and provisioning protocol or > to do image > > > download. > > > > > > > Going back to one of my first statements on this topic > and to bring this > > > arou > > > >nd again to why this discussion is important to the > working group while > > > evalua > > > >ting protocols, independent implementations of LWAPP can > be built from > > > the pro > > > >tocol specification, alone. That same statement cannot > be made about > > > SLAPP. > > > > > > Wrong! SLAPP includes a complete provisioning and control > protocol. > > > > > > Dan. > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Sep 03 20:53:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBikw-0000fu-5E for capwap-archive@megatron.ietf.org; Sat, 03 Sep 2005 20:53:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02731 for ; Sat, 3 Sep 2005 20:53:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAD0D20669; Sat, 3 Sep 2005 20:53:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC8DD2062F; Sat, 3 Sep 2005 20:53:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E49442062F for ; Sat, 3 Sep 2005 20:52:42 -0400 (EDT) Received: from oz.twisted.net (oz.twisted.net [69.211.34.241]) by mail.frascone.com (Postfix) with ESMTP id 0D52D204F3 for ; Sat, 3 Sep 2005 20:52:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by oz.twisted.net (Postfix) with ESMTP id AFDAB599B98 for ; Sat, 3 Sep 2005 20:02:01 -0500 (CDT) Received: from oz.twisted.net ([127.0.0.1]) by localhost (oz.twisted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45297-05 for ; Sat, 3 Sep 2005 20:02:01 -0500 (CDT) Received: from noodle (sindrome.twisted.net [172.16.0.5]) by oz.twisted.net (Postfix) with ESMTP id 80B4A598EFD for ; Sat, 3 Sep 2005 20:02:00 -0500 (CDT) Reply-To: From: "Troy Dixler" To: Subject: RE: [Capwap] IPR issues MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcWwzMoTXLOp+X6PR7aX9FlQgKuY5AAHUEow In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507EE0F2E@nl0006exch001u.nl.lucent.com> Message-Id: <20050904010200.80B4A598EFD@oz.twisted.net> X-Virus-Scanned: by amavisd-new at twisted.net X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sat, 3 Sep 2005 19:51:32 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The specific thread I'm referring to has been referenced below. The language that is in this thread needs to be addressed. I equally read the IPR notice that was sent up. We as a working group need to understand exactly what is in this patent application and engineer around it. I am not going to find myself in the scenario that Dan spelled out and Pat did not expressly clarify. The IPR claim to Airespace/Cisco has been placed here and does not give us the information necessary to know specifically what within LWAPP is being claimed. http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamoby-lwapp.txt Additionally the thread is below between Dan and Pat that sparked this initial E-mail to the list. > Pat, > > If LWAPP were to become a draft standard it sounds like Cisco would > be able to use other companies IPR on things (like accurate location > determination or rogue detection or ...) without license and if that > company tried to stop Cisco then Cisco would bring out the LWAPP club. > Then they either swap licenses, the company gets no benefit from > their IPR, or the unfortunate company pays to implement a standard. > > So it looks like if everybody has to implement LWAPP because it was > the draft standard then they'd have to give up some part of their patent > portfolio to Cisco if they try to assert any of it. I don't think that > sounds like a very good deal. > > Perhaps you could explain _exactly_ what parts of LWAPP you think > are covered by your pending applications so that we make sure none of > that is in the final CAPWAP spec. > > Dan. > > > On Tue, 30 Aug 2005 07:30:15 PDT you wrote > > The royalty free license would extend only to those who do not assert > > against the systems that utilize LWAPP whether or not their assertions > > relate to LWAPP itself. The prior IPR statement carries on through > > Cisco. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 05 04:14:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECC7H-0004hS-99 for capwap-archive@megatron.ietf.org; Mon, 05 Sep 2005 04:14:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02266 for ; Mon, 5 Sep 2005 04:14:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3C96204FA; Mon, 5 Sep 2005 04:14:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B90820377; Mon, 5 Sep 2005 04:14:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9F39020377 for ; Mon, 5 Sep 2005 04:13:16 -0400 (EDT) Received: from staff-mail.rp.edu.sg (staff-mail.rp.edu.sg [202.21.158.80]) by mail.frascone.com (Postfix) with ESMTP id AB13E202CA for ; Mon, 5 Sep 2005 04:13:12 -0400 (EDT) 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 Message-ID: <9C374CF75527504394E573E1937136C4015AB040@staff-mail.rp.edu.sg> Thread-Topic: Simple and complete proposal for CAPWAP thread-index: AcWwtE4qXTyYxn7xTtKZaXCmyuQhtABO+6yA From: "Richard Gwee" To: "Partha Narasimhan" , "Dan Harkins" Cc: , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Simple and complete proposal for CAPWAP Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 5 Sep 2005 16:13:07 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, I do agree in a way that the CAPWAP protocol should be simple and complete. From my perspective, rather than considering which proposed protocol would best represent the basis for CAPWAP, I feel that each CAPWAP proposal does have its unique strength in certain areas. It will be best if the WG can look at combining all of these individual strengths of the four protocols for CAPWAP. Thanks and Regards Richard Gwee -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan Sent: Sunday, September 04, 2005 2:20 AM To: Dan Harkins Cc: troy@twisted.net; capwap@frascone.com Subject: Re: [Capwap] this is not the thread on expanded discussion on regulatory certification which has now officially ended I concur with Dan regarding IPR and SLAPP. Our goal was to come up with=20 a proposal that re-used existing protocols as much as possible resulting in a simple, yet complete proposal. Thanks partha Dan Harkins wrote: > Troy, > > There is no IPR claim on SLAPP to remove.=20 > > Dan. > >On Sat, 03 Sep 2005 08:28:56 CDT you wrote > =20 > >>Guys, >> >>I've been watching the argument on this thread and feel that it's time to >>make a statement as a working group member. There are two very separate >>arguments going on here. One is related to IPR claims and the other around >>image download and FCC violations. I am not making this comment around the >>image download portion but believe it's essential to discuss the IPR issue. >> >>I've seen the IPR game getting out of hand within the IETF for way too long. >>There are way too many drafts that are coming into the IETF standards >>process claiming IPR. =20 >> >>The purpose for the CAPWAP working group is to create an OPEN standard that >>all vendors can implement and show interoperability. Regardless of the >>image download argument, before I'll stand up and back the LWAPP or SLAPP >>contribution, I want Cisco as well as Trapeze to remove any notion of owing >>IPR where they can go after other vendors that implement an IETF standard. >>That simply does not wash. =20 >> >>If the IPR comment stands then we as a working group must engineer around >>any/all requirements and come up with a standard that does not allow one >>vendor to have that type of power. =20 >> >>I do not buy into any comments such as "we would never do it" or "we want to >>contribute to this moving forward" etc. If that is the case, drop the IPR >>claim and then we can go back to considering what protocol would best >>represent the basis for CAPWAP. >> >>The notion of trying to move on from this topic and even consider using a >>protocol that has this type of IPR claim is ridiculous (IMHO). I want an >>IPR free protocol standard out of this group. >> >>So there are two questions. Will both the main authors of each of the specs >>remove any/all IPR claims for consideration of being in the spec? It's a >>simple question of yes or no. Please do not present a long reply without >>answering it as a binary decision. >> >>-Troy >> >> >> =20 >> >>>-----Original Message----- >>>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>>Behalf Of Dan Harkins >>>Sent: Saturday, September 03, 2005 12:53 AM >>>To: Bob O'Hara (boohara) >>>Cc: capwap@frascone.com >>>Subject: Re: [Capwap] Expanded discussion on regulatory certification >>> >>> Bob, >>> >>>On Fri, 02 Sep 2005 13:15:10 PDT you wrote >>>[snip] >>> =20 >>> >>>>Both the SLAPP and LWAPP protocol proposals include the ability to >>>> =20 >>>> >>>download c >>> =20 >>> >>>>ode to an AP/WTP. The difference between the two is that CAPWAP requires >>>> =20 >>>> >>>an a >>> =20 >>> >>>>uthentication signature must be validated before a download can be used, >>>> =20 >>>> >>>while >>> =20 >>> >>>>SLAPP has no such mechanism and specifically allows download of code >>>> =20 >>>> >>>from sou >>> =20 >>> >>>>rces other than the manufacturer or an authorized delegate of the >>>> =20 >>>> >>>manufacturer >>> =20 >>> >>>>. This is a significant difference between the two protocols and needs >>>> =20 >>>> >>>to be >>> =20 >>> >>>>considered when evaluating the protocols during this phase of selecting >>>> =20 >>>> >>>the ba >>> =20 >>> >>>>sis for CAPWAP standardization. >>>> =20 >>>> >>>"Both the SLAPP and LWAPP protocol proposals.... The difference between >>>the >>>two is that CAPWAP requires an authentication signature must be validated >>>before a download can be used, while SLAPP has no such mechanism...." >>> >>>LWAPP =3D CAPWAP? I think you're getting a little excited here Bob. Either >>>that or you know something that has not been made public yet. >>> >>>What you don't know is how SLAPP works. Please go read the spec. There is >>>an authentication step PRIOR to the AC and WTP deciding whether to proceed >>>to the full-fledged control and provisioning protocol or to do image >>>download. >>> >>> =20 >>> >>>>Going back to one of my first statements on this topic and to bring this >>>> =20 >>>> >>>arou >>> =20 >>> >>>>nd again to why this discussion is important to the working group while >>>> =20 >>>> >>>evalua >>> =20 >>> >>>>ting protocols, independent implementations of LWAPP can be built from >>>> =20 >>>> >>>the pro >>> =20 >>> >>>>tocol specification, alone. That same statement cannot be made about >>>> =20 >>>> >>>SLAPP. >>> >>>Wrong! SLAPP includes a complete provisioning and control protocol. >>> >>> Dan. >>> >>>_______________________________________________ >>>Capwap mailing list >>>Capwap@frascone.com >>>http://mail.frascone.com/mailman/listinfo/capwap >>> =20 >>> >>_______________________________________________ >>Capwap mailing list >>Capwap@frascone.com >>http://mail.frascone.com/mailman/listinfo/capwap >> =20 >> >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap > =20 > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 = Website: www.rp.sg . Fax: +65 6415-1310 . From April 2006, we will be located in our new home at 9 Woodlands = Avenue 9,Singapore 738964=20 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 Quality Class = (SQC) certification, People Developer Standards and QEHS standards (ISO = 9001, 14001 and OHSAS 18001 certifications). --------------------------------------------------------------------- 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. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 06 00:37:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECVCp-0007Z1-Lk for capwap-archive@megatron.ietf.org; Tue, 06 Sep 2005 00:37:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21104 for ; Tue, 6 Sep 2005 00:37:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 75EE2204AC; Tue, 6 Sep 2005 00:37:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCF03204FA; Tue, 6 Sep 2005 00:37:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 602F9204FA for ; Tue, 6 Sep 2005 00:36:03 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 3C744204AC for ; Tue, 6 Sep 2005 00:36:00 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j864XEGP021444 for ; Tue, 6 Sep 2005 00:33:14 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j864XDGP021439 for ; Tue, 6 Sep 2005 00:33:13 -0400 (EDT) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Simple and complete proposal for CAPWAP Message-ID: Thread-Topic: [Capwap] Simple and complete proposal for CAPWAP Thread-Index: AcWwtE4qXTyYxn7xTtKZaXCmyuQhtABO+6yAACk4GuA= From: "Mani, Mahalingam (Mahalingam)" To: "Richard Gwee" , "Partha Narasimhan" , "Dan Harkins" Cc: , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 5 Sep 2005 22:35:54 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Richard, At the outset of evaluation - we have not ruled out (for evaluation) to recommend and WG to agree on best collective aspects of the protocols - should they make sense. So it is within scope for such a protocol to emerge; the objective being to arrive at one consensus version to be refined further as needed to fit any new discoveries of requirements. -mani -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Richard Gwee Sent: Monday, September 05, 2005 1:13 AM To: Partha Narasimhan; Dan Harkins Cc: troy@twisted.net; capwap@frascone.com Subject: [Capwap] Simple and complete proposal for CAPWAP Hi, I do agree in a way that the CAPWAP protocol should be simple and complete. From my perspective, rather than considering which proposed protocol would best represent the basis for CAPWAP, I feel that each CAPWAP proposal does have its unique strength in certain areas. It will be best if the WG can look at combining all of these individual strengths of the four protocols for CAPWAP. Thanks and Regards Richard Gwee -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan Sent: Sunday, September 04, 2005 2:20 AM To: Dan Harkins Cc: troy@twisted.net; capwap@frascone.com Subject: Re: [Capwap] this is not the thread on expanded discussion on regulatory certification which has now officially ended I concur with Dan regarding IPR and SLAPP. Our goal was to come up with=20 a proposal that re-used existing protocols as much as possible resulting in a simple, yet complete proposal. Thanks partha Dan Harkins wrote: > Troy, > > There is no IPR claim on SLAPP to remove.=20 > > Dan. > >On Sat, 03 Sep 2005 08:28:56 CDT you wrote > =20 > >>Guys, >> >>I've been watching the argument on this thread and feel that it's time to >>make a statement as a working group member. There are two very separate >>arguments going on here. One is related to IPR claims and the other around >>image download and FCC violations. I am not making this comment around the >>image download portion but believe it's essential to discuss the IPR issue. >> >>I've seen the IPR game getting out of hand within the IETF for way too long. >>There are way too many drafts that are coming into the IETF standards >>process claiming IPR. =20 >> >>The purpose for the CAPWAP working group is to create an OPEN standard that >>all vendors can implement and show interoperability. Regardless of the >>image download argument, before I'll stand up and back the LWAPP or SLAPP >>contribution, I want Cisco as well as Trapeze to remove any notion of owing >>IPR where they can go after other vendors that implement an IETF standard. >>That simply does not wash. =20 >> >>If the IPR comment stands then we as a working group must engineer around >>any/all requirements and come up with a standard that does not allow one >>vendor to have that type of power. =20 >> >>I do not buy into any comments such as "we would never do it" or "we want to >>contribute to this moving forward" etc. If that is the case, drop the IPR >>claim and then we can go back to considering what protocol would best >>represent the basis for CAPWAP. >> >>The notion of trying to move on from this topic and even consider using a >>protocol that has this type of IPR claim is ridiculous (IMHO). I want an >>IPR free protocol standard out of this group. >> >>So there are two questions. Will both the main authors of each of the specs >>remove any/all IPR claims for consideration of being in the spec? It's a >>simple question of yes or no. Please do not present a long reply without >>answering it as a binary decision. >> >>-Troy >> >> >> =20 >> >>>-----Original Message----- >>>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>>Behalf Of Dan Harkins >>>Sent: Saturday, September 03, 2005 12:53 AM >>>To: Bob O'Hara (boohara) >>>Cc: capwap@frascone.com >>>Subject: Re: [Capwap] Expanded discussion on regulatory certification >>> >>> Bob, >>> >>>On Fri, 02 Sep 2005 13:15:10 PDT you wrote >>>[snip] >>> =20 >>> >>>>Both the SLAPP and LWAPP protocol proposals include the ability to >>>> =20 >>>> >>>download c >>> =20 >>> >>>>ode to an AP/WTP. The difference between the two is that CAPWAP requires >>>> =20 >>>> >>>an a >>> =20 >>> >>>>uthentication signature must be validated before a download can be used, >>>> =20 >>>> >>>while >>> =20 >>> >>>>SLAPP has no such mechanism and specifically allows download of code >>>> =20 >>>> >>>from sou >>> =20 >>> >>>>rces other than the manufacturer or an authorized delegate of the >>>> =20 >>>> >>>manufacturer >>> =20 >>> >>>>. This is a significant difference between the two protocols and needs >>>> =20 >>>> >>>to be >>> =20 >>> >>>>considered when evaluating the protocols during this phase of selecting >>>> =20 >>>> >>>the ba >>> =20 >>> >>>>sis for CAPWAP standardization. >>>> =20 >>>> >>>"Both the SLAPP and LWAPP protocol proposals.... The difference between >>>the >>>two is that CAPWAP requires an authentication signature must be validated >>>before a download can be used, while SLAPP has no such mechanism...." >>> >>>LWAPP =3D CAPWAP? I think you're getting a little excited here Bob. Either >>>that or you know something that has not been made public yet. >>> >>>What you don't know is how SLAPP works. Please go read the spec. There is >>>an authentication step PRIOR to the AC and WTP deciding whether to proceed >>>to the full-fledged control and provisioning protocol or to do image >>>download. >>> >>> =20 >>> >>>>Going back to one of my first statements on this topic and to bring this >>>> =20 >>>> >>>arou >>> =20 >>> >>>>nd again to why this discussion is important to the working group while >>>> =20 >>>> >>>evalua >>> =20 >>> >>>>ting protocols, independent implementations of LWAPP can be built from >>>> =20 >>>> >>>the pro >>> =20 >>> >>>>tocol specification, alone. That same statement cannot be made about >>>> =20 >>>> >>>SLAPP. >>> >>>Wrong! SLAPP includes a complete provisioning and control protocol. >>> >>> Dan. >>> >>>_______________________________________________ >>>Capwap mailing list >>>Capwap@frascone.com >>>http://mail.frascone.com/mailman/listinfo/capwap >>> =20 >>> >>_______________________________________________ >>Capwap mailing list >>Capwap@frascone.com >>http://mail.frascone.com/mailman/listinfo/capwap >> =20 >> >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap > =20 > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 Website: www.rp.sg . Fax: +65 6415-1310 . From April 2006, we will be located in our new home at 9 Woodlands Avenue 9,Singapore 738964=20 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 Quality Class (SQC) certification, People Developer Standards and QEHS standards (ISO 9001, 14001 and OHSAS 18001 certifications). --------------------------------------------------------------------- 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. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 06 09:47:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECdn5-0002pG-DJ for capwap-archive@megatron.ietf.org; Tue, 06 Sep 2005 09:47:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27766 for ; Tue, 6 Sep 2005 09:47:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB27C2056A; Tue, 6 Sep 2005 09:47:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A7E0205F1; Tue, 6 Sep 2005 09:47:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E0A3205F1 for ; Tue, 6 Sep 2005 09:46:06 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 2DF212056A for ; Tue, 6 Sep 2005 09:46:05 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Tue, 06 Sep 2005 09:47:46 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 9966524FC7 for ; Tue, 6 Sep 2005 09:47:15 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Sep 2005 09:41:08 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601329BB56@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: capwap@frascone.com Subject: [Capwap] In-band/out-of-band firmware download MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 6 Sep 2005 09:46:18 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) One implicit technical issue that I believe has come out of the regulatory discussion is regading firmware download. There seems to be two different mechanisms that are proposed for firmware download to the WTP: one uses the control channel between the AC and the WTP (I call that an in-band mechanism) and the other uses a separate protocol, independent of the control channel. An in-band mechanism provides a simpler mechanism for monitoring the progress of the firmware download and simplified state management. An out-of-band mechanism relies on other protocols (sftp, ftp, tftp), which would likely provide a more robust mechanism for download, but perhaps a slightly more compicated state machine. What is the feeling of the group on how firmware download should work? Cheers, Mike _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 06 11:07:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECf2U-00007l-AT for capwap-archive@megatron.ietf.org; Tue, 06 Sep 2005 11:07:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02925 for ; Tue, 6 Sep 2005 11:07:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08B8820629; Tue, 6 Sep 2005 11:07:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7369B2060F; Tue, 6 Sep 2005 11:07:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 006862060F for ; Tue, 6 Sep 2005 11:06:10 -0400 (EDT) Received: from gwo2.mbox.net (gateout02.mbox.net [165.212.64.22]) by mail.frascone.com (Postfix) with ESMTP id 3F13B2056A for ; Tue, 6 Sep 2005 11:06:06 -0400 (EDT) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id 90904163C21; Tue, 6 Sep 2005 15:05:44 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 911JiFPFQ0431Mo2; Tue, 06 Sep 2005 15:05:43 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 909JiFPFp0136Mo2; Tue, 06 Sep 2005 15:05:41 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Tue, 06 Sep 2005 15:05:41 GMT X-USANET-Source: 165.212.116.254 IN bhandaru@nexthop.com gw1.EXCHPROD.USA.NET X-USANET-MsgId: XID742JiFPFp2687Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by gw1.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 09:05:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 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] In-band/out-of-band firmware download Message-ID: <7ADC90A5E95BA74DA5CA5A6C390D5305011EECBD@VS4.EXCHPROD.USA.NET> Thread-Topic: [Capwap] In-band/out-of-band firmware download thread-index: AcWy6YKpeB/BJg6MSyKIVsfgZNy4EwACg9HA From: "Nehru Bhandaru" To: "Michael Montemurro" , X-OriginalArrivalTime: 06 Sep 2005 15:05:33.0375 (UTC) FILETIME=[6DCB94F0:01C5B2F4] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 6 Sep 2005 09:05:06 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Robustness provided by out-of-band mechanism is probably useful. However, the out-of-band dowloaded firmware must be authenticated - perhaps using the mechanism used by the control channel - so that appropriate policy can be enforced. One questions comes to mind - why not make the in-band mechanism robust? - Nehru -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Michael Montemurro Sent: Tuesday, September 06, 2005 9:46 AM To: capwap@frascone.com Subject: [Capwap] In-band/out-of-band firmware download =20 One implicit technical issue that I believe has come out of the regulatory discussion is regading firmware download. There seems to be two different mechanisms that are proposed for firmware download to the WTP: one uses the control channel between the AC and the WTP (I call that an in-band mechanism) and the other uses a separate protocol, independent of the control channel. =20 An in-band mechanism provides a simpler mechanism for monitoring the progress of the firmware download and simplified state management. An out-of-band mechanism relies on other protocols (sftp, ftp, tftp), which would likely provide a more robust mechanism for download, but perhaps a slightly more compicated state machine. =20 What is the feeling of the group on how firmware download should work? =20 Cheers, =20 Mike _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 06 12:41:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECgVU-00078v-85 for capwap-archive@megatron.ietf.org; Tue, 06 Sep 2005 12:41:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07207 for ; Tue, 6 Sep 2005 12:41:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5FE7320629; Tue, 6 Sep 2005 12:41:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 582AA2056A; Tue, 6 Sep 2005 12:41:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D82D204EA for ; Tue, 6 Sep 2005 12:40:18 -0400 (EDT) Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) by mail.frascone.com (Postfix) with ESMTP id B2EBF2056A for ; Tue, 6 Sep 2005 12:40:14 -0400 (EDT) Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 06 Sep 2005 09:40:11 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,172,1122879600"; d="scan'208"; a="499821664:sNHT83055320" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 09:40:10 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5B301.A563F08E" Subject: RE: [Capwap] IPR issues Message-ID: X-MS-Has-Attach: yes Thread-Topic: [Capwap] IPR issues Thread-Index: AcWwzMoTXLOp+X6PR7aX9FlQgKuY5AAHUEowAIWs6eA= From: "Changming Liu" To: , X-OriginalArrivalTime: 06 Sep 2005 16:40:10.0745 (UTC) FILETIME=[A5C57E90:01C5B301] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 6 Sep 2005 09:40:10 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5B301.A563F08E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Troy, It was me who started this discussion although Pat and Dan carried it much further :-). It has been very helpful for me to watch this email conversation. This is not to take any credit but want one of my trivial questions to be answered by Pat. Please see attached email. Changming -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Troy Dixler Sent: Saturday, September 03, 2005 5:52 PM To: capwap@frascone.com Subject: RE: [Capwap] IPR issues The specific thread I'm referring to has been referenced below. The language that is in this thread needs to be addressed. I equally read the IPR notice that was sent up. We as a working group need to understand exactly what is in this patent application and engineer around it. I am not going to find myself in the scenario that Dan spelled out and Pat did not expressly clarify.=20 The IPR claim to Airespace/Cisco has been placed here and does not give us the information necessary to know specifically what within LWAPP is being claimed. http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamoby-lwapp.t xt Additionally the thread is below between Dan and Pat that sparked this initial E-mail to the list. > Pat, >=20 > If LWAPP were to become a draft standard it sounds like Cisco would > be able to use other companies IPR on things (like accurate location > determination or rogue detection or ...) without license and if that > company tried to stop Cisco then Cisco would bring out the LWAPP club. > Then they either swap licenses, the company gets no benefit from > their IPR, or the unfortunate company pays to implement a standard. >=20 > So it looks like if everybody has to implement LWAPP because it was > the draft standard then they'd have to give up some part of their patent > portfolio to Cisco if they try to assert any of it. I don't think that > sounds like a very good deal. >=20 > Perhaps you could explain _exactly_ what parts of LWAPP you think > are covered by your pending applications so that we make sure none of > that is in the final CAPWAP spec. >=20 > Dan. >=20 >=20 > On Tue, 30 Aug 2005 07:30:15 PDT you wrote > > The royalty free license would extend only to those who do not assert > > against the systems that utilize LWAPP whether or not their assertions > > relate to LWAPP itself. The prior IPR statement carries on through > > Cisco. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap ------_=_NextPart_001_01C5B301.A563F08E Content-Type: message/rfc822 Received: from alpha.jnpr.net ([172.24.18.126]) by hadron.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Aug 2005 23:06:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Received: from pinot.juniper.net ([207.17.137.58]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Aug 2005 23:06:01 -0700 Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) by pinot.juniper.net (8.12.9/8.12.3) with ESMTP id j7N65pPn058878; Mon, 22 Aug 2005 23:05:51 -0700 (PDT) Received: from unknown (HELO mail.frascone.com) (204.49.99.9) by borg.juniper.net with ESMTP; 22 Aug 2005 23:05:51 -0700 Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 96A512050F; Tue, 23 Aug 2005 02:05:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB48720503; Tue, 23 Aug 2005 02:05:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4E52720503 for ; Tue, 23 Aug 2005 02:04:47 -0400 (EDT) Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) by mail.frascone.com (Postfix) with ESMTP id B504F20500 for ; Tue, 23 Aug 2005 02:04:43 -0400 (EDT) Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 22 Aug 2005 23:04:43 -0700 Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Aug 2005 23:04:42 -0700 Content-class: urn:content-classes:message Return-Path: X-OriginalArrivalTime: 23 Aug 2005 06:04:42.0330 (UTC) FILETIME=[8DAE93A0:01C5A7A8] X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 X-JNPR-Received-From: outside X-Scanned-By: MIMEDefang 2.39 List-Id: A list for CAPWAP technical discussions X-Mailman-Version: 2.0.13 X-BeenThere: capwap@frascone.com List-Archive: List-Post: Errors-To: capwap-admin@frascone.com Delivered-To: capwap@frascone.com X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) X-Original-To: capwap@frascone.com X-BrightmailFiltered: true X-IronPort-AV: i="3.96,132,1122879600"; d="scan'208,217"; a="488865978:sNHT55668104" X-Brightmail-Tracker: AAAAAA== Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals Date: Mon, 22 Aug 2005 23:04:41 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals Thread-Index: AcWnqI0nRoq8gaxpSYKK/ejoIORzNg== List-Help: List-Subscribe: , List-Unsubscribe: , From: "Changming Liu" To: "Darren Loher" , "Cheng Hong" , "Gopal Dommety" , "Mani, Mahalingam \(Mahalingam\)" Cc: Content-Transfer-Encoding: quoted-printable Darren, =20 Thanks for the info. Just took a quick look at the Airespace's Statement about IPR and found a statement below:=20 =20 "Airespace hereby covenants that it will not assert any patent claims contained in any of the above-identified pending patent applications (if and when issued as a Patent) against any party that makes, uses, sells, imports, or offers for sale, an implementation of the LWAPP protocol as specified in the Specification, assuming it is adopted." =20 I have a trivial question: What does "adopted" mean? Does it mean when it is selected by the eval team as the "chosen one", when it becomes an experimental standard or when it becomes a full standard? If the last one is the case, how can other vendors implement it so that two or more interoperable copies can be implemented to meet RFC2026's requirement? =20 =20 Pat, do you mind elaborating it a bit more?=20 =20 Thanks. =20 Changming =20 ________________________________ From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 Sent: Monday, August 22, 2005 4:49 PM To: Changming Liu; Cheng Hong; Gopal Dommety; Mani, Mahalingam (Mahalingam) Cc: capwap@frascone.com Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals =20 I've asked similar questions. To my knowledge, the only intellectual property disclosure that has been filed in the CAPWAP working group is regarding LWAPP. You can read it at: =20 http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamoby-lwapp.t xt =20 I have not seen any disclosure from the authors of CTP, WiCoP or SLAPP. =20 -Darren =20 =20 ________________________________ From: Changming Liu [mailto:cliu@juniper.net]=20 Sent: Friday, August 19, 2005 8:50 PM To: Darren Loher; Cheng Hong; Gopal Dommety; Mani, Mahalingam (Mahalingam) Cc: capwap@frascone.com Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals =20 This brings up a very good question: is there any license/patent issue for any candidate proposal to be implemented by any vendor other than the vendors of the authors? If so, has it be raised somewhere so that whoever is willing to implement is aware of it? =20 Thanks. =20 Changming -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Wednesday, August 17, 2005 7:58 AM To: Cheng Hong; Gopal Dommety; Mani, Mahalingam (Mahalingam) Cc: capwap@frascone.com Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals =20 One of the tenets of the IETF is "running code". This is in fact a requirement to elevating a draft to a draft-standard. It is also (on the "soft-side") a measure of strength and value for a given standard when it is in place. We are not at that stage yet, but it is a hurdle that will need to be overcome to get a standard. =20 From BCP 9 / rfc2026: 4.1.2 Draft Standard =20 A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful. =20 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. =20 The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations. The documentation must include information about the support of each of the individual options and features. This documentation should be submitted to the Area Director with the protocol action request. (see Section 6) =20 =20 =20 =20 -Darren =20 =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Cheng Hong Sent: Tuesday, August 16, 2005 9:20 PM To: Gopal Dommety; Mani, Mahalingam (Mahalingam) Cc: capwap@frascone.com Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals =20 Hi Gopal, =20 Having running code is nice. However, before the group agree on the common objective details and selection criteria, running code means nothing. Interoperability is achieved by a well defined specification, not the implementation of that specification (the running code). People can implement the IP ugly, but it should still be able to interoperate with other IP nodes. I guess the top priority now is to work on a specification that contains features to meet our agreed objectives. Emphasizing on running code now will just deviate us from the real goal. =20 cheers =20 Cheng Hong =20 =20 =20 =09 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Gopal Dommety Sent: Wednesday, August 17, 2005 2:34 AM To: Mani, Mahalingam (Mahalingam) Cc: capwap@frascone.com Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals =09 Thanks for the clarification. I am bit surprised that there is no need for an implentation of a protocol for it to be selected.=20 =09 I understand that making minor extensions to Protocols are necessary. However, Fundmental/Significant deviations between the specifications and implentations will not get us anycloser to the goal of interoperability.=20 =09 Cheers, -Gopal =09 At 11:26 PM 8/15/2005 -0600, Mani, Mahalingam (Mahalingam) wrote: There s no emphasis yet to running code at least not set as an Objective or Evaluation criterion. =09 =20 =09 One way to look at this is that as many as 15-16 implementation experiences broadly fell into two categories; and the focus was to identify and seek commonality in architecture/split which by itself has been something to converge on; before contemplating possible implementation adoptions given most of the candidate protocol specs kept evolving quite a bit across the last two-three IETF sessions. =09 =20 =09 -mani =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Gopal Dommety Sent: Monday, August 15, 2005 6:04 PM To: capwap@frascone.com Subject: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals =09 =20 =09 Hello All, =09 During the last IETF, I realized that some of the submitted proposals might differ from what is implemented significantly. I was wondering if there is any documentation of the number of implemetations for each of the CAPWAP Protocols (as submitted)? Is there any emphasis to "running code" for the CAPWAP protocols being considered? =09 =09 Regards,=20 =09 -Gopal=20 ------_=_NextPart_001_01C5B301.A563F08E-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 06 13:02:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECgpn-0001pX-5j for capwap-archive@megatron.ietf.org; Tue, 06 Sep 2005 13:02:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08008 for ; Tue, 6 Sep 2005 13:02:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3BDBB2062C; Tue, 6 Sep 2005 13:02:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8027520611; Tue, 6 Sep 2005 13:02:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CCBD720611 for ; Tue, 6 Sep 2005 13:01:53 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id C7CF9204EA for ; Tue, 6 Sep 2005 13:01:50 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 06 Sep 2005 10:01:50 -0700 X-IronPort-AV: i="3.96,172,1122879600"; d="scan'208"; a="658435114:sNHT33036136" 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 j86H1N0d006492; Tue, 6 Sep 2005 10:01:47 -0700 (PDT) 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); Tue, 6 Sep 2005 10:01:44 -0700 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] IPR issues Message-ID: <4FF84B0BC277FF45AA27FE969DD956A29C3DF7@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] IPR issues Thread-Index: AcWwzMoTXLOp+X6PR7aX9FlQgKuY5AAHUEowAIWs6eAAAPNTMA== From: "Pat Calhoun (pacalhou)" To: "Changming Liu" , , X-OriginalArrivalTime: 06 Sep 2005 17:01:44.0341 (UTC) FILETIME=[A8D09450:01C5B304] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 6 Sep 2005 10:01:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable From the beginning Airespace, and now Cisco, has shown significant interest in seeing products get introduced in the market, and has shown our commitment by providing free access to the patents listed in the disclosure. That said, in our view, adopt means becoming an RFC. As stated above, we have no interest in slowing down the process, or even hindering interoperability testing prior to the issuance of an RFC. Therefore, Cisco will gladly grant licenses prior to this time on a case-by-case basis. If you have such a need, please contact dlang@cisco.com. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Changming Liu > Sent: Tuesday, September 06, 2005 9:40 AM > To: troy@twisted.net; capwap@frascone.com > Subject: RE: [Capwap] IPR issues >=20 > Troy, >=20 > It was me who started this discussion although Pat and Dan=20 > carried it much further :-). It has been very helpful for me=20 > to watch this email conversation. This is not to take any=20 > credit but want one of my trivial questions to be answered by=20 > Pat. Please see attached email. >=20 >=20 > Changming >=20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Troy Dixler > Sent: Saturday, September 03, 2005 5:52 PM > To: capwap@frascone.com > Subject: RE: [Capwap] IPR issues >=20 > The specific thread I'm referring to has been referenced=20 > below. The language that is in this thread needs to be=20 > addressed. I equally read the IPR notice that was sent up.=20 > We as a working group need to understand exactly what is in=20 > this patent application and engineer around it. I am not=20 > going to find myself in the scenario that Dan spelled out and=20 > Pat did not expressly clarify.=20 >=20 > The IPR claim to Airespace/Cisco has been placed here and=20 > does not give us the information necessary to know=20 > specifically what within LWAPP is being claimed. > http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamo by-lwapp.t > xt >=20 >=20 > Additionally the thread is below between Dan and Pat that=20 > sparked this initial E-mail to the list. >=20 > > Pat, > >=20 > > If LWAPP were to become a draft standard it sounds like=20 > Cisco would=20 > > be able to use other companies IPR on things (like accurate=20 > location=20 > > determination or rogue detection or ...) without license=20 > and if that=20 > > company tried to stop Cisco then Cisco would bring out the=20 > LWAPP club. > > Then they either swap licenses, the company gets no benefit=20 > from their=20 > > IPR, or the unfortunate company pays to implement a standard. > >=20 > > So it looks like if everybody has to implement LWAPP=20 > because it was=20 > > the draft standard then they'd have to give up some part of their > patent > > portfolio to Cisco if they try to assert any of it. I don't=20 > think that=20 > > sounds like a very good deal. > >=20 > > Perhaps you could explain _exactly_ what parts of LWAPP you think=20 > > are covered by your pending applications so that we make=20 > sure none of=20 > > that is in the final CAPWAP spec. > >=20 > > Dan. > >=20 > >=20 > > On Tue, 30 Aug 2005 07:30:15 PDT you wrote > > > The royalty free license would extend only to those who do not > assert > > > against the systems that utilize LWAPP whether or not their > assertions > > > relate to LWAPP itself. The prior IPR statement carries=20 > on through=20 > > > Cisco. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 06 14:16:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChzO-0005XC-9s for capwap-archive@megatron.ietf.org; Tue, 06 Sep 2005 14:16:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11256 for ; Tue, 6 Sep 2005 14:16:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C818420681; Tue, 6 Sep 2005 14:16:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15C9120613; Tue, 6 Sep 2005 14:16:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D49220613 for ; Tue, 6 Sep 2005 14:15:46 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by mail.frascone.com (Postfix) with ESMTP id 33F6220611 for ; Tue, 6 Sep 2005 14:15:43 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j86IFa1v013036; Tue, 6 Sep 2005 21:15:40 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Sep 2005 21:14:42 +0300 Received: from l5131412.nokia.com ([10.241.163.153]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 6 Sep 2005 21:14:42 +0300 Message-Id: <6.2.1.2.2.20050906110612.025508f0@daebe102.noe.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: "Pat Calhoun (pacalhou)" From: Bob Hinden Subject: RE: [Capwap] IPR issues Cc: "Changming Liu" , , In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A29C3DF7@xmb-sjc-235.amer.ci sco.com> References: <4FF84B0BC277FF45AA27FE969DD956A29C3DF7@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 06 Sep 2005 18:14:42.0482 (UTC) FILETIME=[DA63E120:01C5B30E] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 06 Sep 2005 11:14:36 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Pat, At 10:01 AM 09/06/2005, Pat Calhoun (pacalhou) wrote: > From the beginning Airespace, and now Cisco, has shown significant >interest in seeing products get introduced in the market, and has shown >our commitment by providing free access to the patents listed in the >disclosure. That said, in our view, adopt means becoming an RFC. As >stated above, we have no interest in slowing down the process, or even >hindering interoperability testing prior to the issuance of an RFC. >Therefore, Cisco will gladly grant licenses prior to this time on a >case-by-case basis. If you have such a need, please contact >dlang@cisco.com. While I am certainly not a patent lawyer as I understand the law, testing an implementation (e.g., interoperability testing) would not cause infringement. Infringement occurs when shipping a product. In my experience, a license would not be needed for interoperability testing any more that it would be required for having a description of the IPR. To repeat, I am not a patent lawyer, etc., etc. Bob _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 06 14:33:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECiFr-0008UY-UE for capwap-archive@megatron.ietf.org; Tue, 06 Sep 2005 14:33:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12037 for ; Tue, 6 Sep 2005 14:33:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D4D12062C; Tue, 6 Sep 2005 14:33:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0647120610; Tue, 6 Sep 2005 14:33:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 223FE20610 for ; Tue, 6 Sep 2005 14:32:18 -0400 (EDT) Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) by mail.frascone.com (Postfix) with ESMTP id AB163205F5 for ; Tue, 6 Sep 2005 14:32:12 -0400 (EDT) Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 06 Sep 2005 11:32:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,172,1122879600"; d="scan'208"; a="499835191:sNHT33589084" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 11:32:11 -0700 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] IPR issues Message-ID: Thread-Topic: [Capwap] IPR issues Thread-Index: AcWwzMoTXLOp+X6PR7aX9FlQgKuY5AAHUEowAIWs6eAAAPNTMAADAefg From: "Changming Liu" To: "Pat Calhoun (pacalhou)" , , X-OriginalArrivalTime: 06 Sep 2005 18:32:11.0620 (UTC) FILETIME=[4BB9A240:01C5B311] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 6 Sep 2005 11:32:10 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pat, Thanks for taking time to answer my questions. What you stated in the email is really helpful. I have one more follow-up question (please bear with me for one more time): There are many different categories of RFCs: standard track, informational, experimental and best practice, etc. Does "becoming an RFC" in your statement below means RFC is a RFC regardless of its category? Sorry for asking such detailed question. But everyone needs to be careful when they are dealing with patent issue :-). Changming -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Tuesday, September 06, 2005 10:02 AM To: Changming Liu; troy@twisted.net; capwap@frascone.com Subject: RE: [Capwap] IPR issues From the beginning Airespace, and now Cisco, has shown significant interest in seeing products get introduced in the market, and has shown our commitment by providing free access to the patents listed in the disclosure. That said, in our view, adopt means becoming an RFC. As stated above, we have no interest in slowing down the process, or even hindering interoperability testing prior to the issuance of an RFC. Therefore, Cisco will gladly grant licenses prior to this time on a case-by-case basis. If you have such a need, please contact dlang@cisco.com. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Changming Liu > Sent: Tuesday, September 06, 2005 9:40 AM > To: troy@twisted.net; capwap@frascone.com > Subject: RE: [Capwap] IPR issues >=20 > Troy, >=20 > It was me who started this discussion although Pat and Dan=20 > carried it much further :-). It has been very helpful for me=20 > to watch this email conversation. This is not to take any=20 > credit but want one of my trivial questions to be answered by=20 > Pat. Please see attached email. >=20 >=20 > Changming >=20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Troy Dixler > Sent: Saturday, September 03, 2005 5:52 PM > To: capwap@frascone.com > Subject: RE: [Capwap] IPR issues >=20 > The specific thread I'm referring to has been referenced=20 > below. The language that is in this thread needs to be=20 > addressed. I equally read the IPR notice that was sent up.=20 > We as a working group need to understand exactly what is in=20 > this patent application and engineer around it. I am not=20 > going to find myself in the scenario that Dan spelled out and=20 > Pat did not expressly clarify.=20 >=20 > The IPR claim to Airespace/Cisco has been placed here and=20 > does not give us the information necessary to know=20 > specifically what within LWAPP is being claimed. > http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamo by-lwapp.t > xt >=20 >=20 > Additionally the thread is below between Dan and Pat that=20 > sparked this initial E-mail to the list. >=20 > > Pat, > >=20 > > If LWAPP were to become a draft standard it sounds like=20 > Cisco would=20 > > be able to use other companies IPR on things (like accurate=20 > location=20 > > determination or rogue detection or ...) without license=20 > and if that=20 > > company tried to stop Cisco then Cisco would bring out the=20 > LWAPP club. > > Then they either swap licenses, the company gets no benefit=20 > from their=20 > > IPR, or the unfortunate company pays to implement a standard. > >=20 > > So it looks like if everybody has to implement LWAPP=20 > because it was=20 > > the draft standard then they'd have to give up some part of their > patent > > portfolio to Cisco if they try to assert any of it. I don't=20 > think that=20 > > sounds like a very good deal. > >=20 > > Perhaps you could explain _exactly_ what parts of LWAPP you think=20 > > are covered by your pending applications so that we make=20 > sure none of=20 > > that is in the final CAPWAP spec. > >=20 > > Dan. > >=20 > >=20 > > On Tue, 30 Aug 2005 07:30:15 PDT you wrote > > > The royalty free license would extend only to those who do not > assert > > > against the systems that utilize LWAPP whether or not their > assertions > > > relate to LWAPP itself. The prior IPR statement carries=20 > on through=20 > > > Cisco. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 07 11:58:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2JO-0001QL-FV for capwap-archive@megatron.ietf.org; Wed, 07 Sep 2005 11:58:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28605 for ; Wed, 7 Sep 2005 11:58:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22065205F5; Wed, 7 Sep 2005 11:58:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1DBD520499; Wed, 7 Sep 2005 11:58:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D92520499 for ; Wed, 7 Sep 2005 11:57:44 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 94A082034F for ; Wed, 7 Sep 2005 11:57:41 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 07 Sep 2005 08:57:41 -0700 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 j87FvG5I004023; Wed, 7 Sep 2005 08:57:38 -0700 (PDT) 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, 7 Sep 2005 08:57:37 -0700 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] In-band/out-of-band firmware download Message-ID: <4FF84B0BC277FF45AA27FE969DD956A29C412B@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] In-band/out-of-band firmware download Thread-Index: AcWy6ajZ/TympsVcRj+fGzoJAtk0MgA2xqLQ From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , X-OriginalArrivalTime: 07 Sep 2005 15:57:37.0674 (UTC) FILETIME=[DE6F86A0:01C5B3C4] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 7 Sep 2005 08:57:36 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Not clear to me why you state that out of band is more robust. I think that being able to piggy back from the existing security association, and encryption channel, between the WTP and the AC has lots of value. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Michael Montemurro > Sent: Tuesday, September 06, 2005 6:46 AM > To: capwap@frascone.com > Subject: [Capwap] In-band/out-of-band firmware download >=20 > One implicit technical issue that I believe has come out of=20 > the regulatory discussion is regading firmware download.=20 > There seems to be two different mechanisms that are proposed=20 > for firmware download to the WTP: one uses the control=20 > channel between the AC and the WTP (I call that an in-band > mechanism) and the other uses a separate protocol,=20 > independent of the control channel.=20 >=20 > An in-band mechanism provides a simpler mechanism for=20 > monitoring the progress of the firmware download and=20 > simplified state management. An out-of-band mechanism relies=20 > on other protocols (sftp, ftp, tftp), which would likely=20 > provide a more robust mechanism for download, but perhaps a=20 > slightly more compicated state machine. >=20 > What is the feeling of the group on how firmware download should work? >=20 > Cheers, >=20 > Mike > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 07 12:30:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2oM-00029I-Pj for capwap-archive@megatron.ietf.org; Wed, 07 Sep 2005 12:30:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00489 for ; Wed, 7 Sep 2005 12:30:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49F6B20616; Wed, 7 Sep 2005 12:30:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3E8D204DA; Wed, 7 Sep 2005 12:30:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 51A39204DA for ; Wed, 7 Sep 2005 12:29:55 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 784CC20499 for ; Wed, 7 Sep 2005 12:29:52 -0400 (EDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 07 Sep 2005 09:29:52 -0700 X-IronPort-AV: i="3.96,176,1122879600"; d="scan'208"; a="210185434:sNHT31175240" 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 j87GTBWT012454; Wed, 7 Sep 2005 09:29:50 -0700 (PDT) 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, 7 Sep 2005 09:29:33 -0700 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] CAPWAP eval team - CTP evaluation Message-ID: <4FF84B0BC277FF45AA27FE969DD956A29C415C@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] CAPWAP eval team - CTP evaluation Thread-Index: AcWkHNdXFH2kf0MFQv+tJziZzFma6gPqEqbg From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 07 Sep 2005 16:29:33.0534 (UTC) FILETIME=[54608FE0:01C5B3C9] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 7 Sep 2005 09:29:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable > With my eval team member hat off, > can I ask how appropriate/feasible/good SNMP would be for=20 > Split MAC WTPs? > CTP's use of SNMP stems originally from managing legacy Local=20 > MAC WTPs.=20 > Can one easily extend it to Split MAC WTPs? > The use of SNMP versus CAPWAP had been discussed earlier in=20 > this mailing list but I forgot what was the conclusion, if any? As others have stated, SNMP requires ASN.1, and this therefore imposes significant per packet overhead to each payload attached to a single message. Putting aside CPU overhead this proposal alsowould create much larger packets, and packet size efficiency is actually very important once we start considering the use of CAPWAP over the air, for such things as mesh networks (or 802.11s). While the IEEE has defined a MIB, history has shown that the MIBs in question have been largely incomplete. The fact that there is yet an AP MIB means that there is no MIB one could actually use TODAY for CAPWAP. So the end result is that every AP vendor out there has their own enterprise specific MIB. Very few products actually make use of the existing MIB, other than as there is work in progress in 802.11v, but this is not expected to complete until Ocotber 2008 (see Group Update/Timelines under http://ieee802.org/11/index.html). So going down this path would require CAPWAP to define the MIBs anyways, eliminating the benefits of reusing IEEE work. So I would much prefer that we stick to the tried and true method of AVPs, which has been very successful for such protocols as RADIUS, etc. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 07 15:48:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5tz-0002pT-T6 for capwap-archive@megatron.ietf.org; Wed, 07 Sep 2005 15:48:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12521 for ; Wed, 7 Sep 2005 15:48:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7ACD92059A; Wed, 7 Sep 2005 15:48:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0CE4C204DA; Wed, 7 Sep 2005 15:48:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50CA0204DA for ; Wed, 7 Sep 2005 15:47:30 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 9E3DA20499 for ; Wed, 7 Sep 2005 15:47:26 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Wed, 07 Sep 2005 15:48:43 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 395462502E; Wed, 7 Sep 2005 15:48:04 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Sep 2005 15:42:04 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601329BDFA@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: "Pat Calhoun (pacalhou)" , capwap@frascone.com Subject: RE: [Capwap] In-band/out-of-band firmware download MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 7 Sep 2005 15:47:11 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Protocols such as ftp and sftp have built-in mechanisms to recover from errors. It's true that if you use an in-band mechanism, you can piggyback off the existing security association and encryption. However, you would have to build capability into the protocol to ensure that you could recover efficiently from errors. This work has already been done for out-of-band protocols. Cheers, Mike > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: September 7, 2005 11:58 AM > To: Michael Montemurro; capwap@frascone.com > Subject: RE: [Capwap] In-band/out-of-band firmware download > > Not clear to me why you state that out of band is more robust. > > I think that being able to piggy back from the existing > security association, and encryption channel, between the WTP > and the AC has lots of value. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Michael Montemurro > > Sent: Tuesday, September 06, 2005 6:46 AM > > To: capwap@frascone.com > > Subject: [Capwap] In-band/out-of-band firmware download > > > > One implicit technical issue that I believe has come out of the > > regulatory discussion is regading firmware download. > > There seems to be two different mechanisms that are proposed for > > firmware download to the WTP: one uses the control channel > between the > > AC and the WTP (I call that an in-band > > mechanism) and the other uses a separate protocol, > independent of the > > control channel. > > > > An in-band mechanism provides a simpler mechanism for > monitoring the > > progress of the firmware download and simplified state > management. An > > out-of-band mechanism relies on other protocols (sftp, ftp, tftp), > > which would likely provide a more robust mechanism for > download, but > > perhaps a slightly more compicated state machine. > > > > What is the feeling of the group on how firmware download > should work? > > > > Cheers, > > > > Mike > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 07 15:52:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5xq-0003LP-Hy for capwap-archive@megatron.ietf.org; Wed, 07 Sep 2005 15:52:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12628 for ; Wed, 7 Sep 2005 15:52:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F0712063C; Wed, 7 Sep 2005 15:52:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B2B82053F; Wed, 7 Sep 2005 15:52:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D1992053F for ; Wed, 7 Sep 2005 15:51:19 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 000A4204DA for ; Wed, 7 Sep 2005 15:51:16 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Wed, 07 Sep 2005 15:51:56 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 83CA925032; Wed, 7 Sep 2005 15:51:16 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Sep 2005 15:45:17 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601329BDFF@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: "Pat Calhoun (pacalhou)" , sarikaya@ieee.org, capwap@frascone.com Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 7 Sep 2005 15:50:28 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) There are a number of reasons why the CTP protocol relies used SNMP payload (not SNMP) for WTP configuration: 1) Protocol Administration: The IEEE defines MIB configuration elements with every amendment to the standard. If the CAPWAP working group adopts an approach of using the SNMP mib definition for configuration of Access Points, it means that the group does not have rev TLV's every time there is a new amendment to the standard. If the MIB does not compile, CAPWAP should go back to the IEEE to fix the MIB. Using existing MIB definitions for configuration also allows the CAPWAP working group to apply the protocol to other wireless technologies without having to derive new configuration elements. Contrary to Pat's statement, I would say that most vendors that supply an SNMP mib with their Access Point use the 802.11 MIB as a basis. Also, I very much doubt that the CAPWAP working group would make use of 802.11 amendments prior to them becoming a standard. Also, if TLV's are adopted for configuration, the CAPWAP working group is likely going to need to rely on the 802.11 MIB to derive new TLV's. 2) Ease of Implementation: Most, if not all enterprise class AP's have an SNMP agent. If CAPWAP relies on SNMP payload for configuration, the existing SNMP agent on the WTP can be used for CAPWAP implementation. We have had a lot of success in using this mechanism to port our protocol across different AP hardware/software platforms. We also have not seen any problems with regard to processor overhead or network overhead. The size of a large configuration packet is approximately around 7k, which would not represent significant network overhead. This protocol is different from RADIUS and other IETF protocols in that it is based on work done by another standards body. However if the SNMP definition has already been done by another standards body, why not use it? Cheers, Mike > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) > Sent: September 7, 2005 12:30 PM > To: sarikaya@ieee.org; capwap@frascone.com > Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation > > > With my eval team member hat off, > > can I ask how appropriate/feasible/good SNMP would be for Split MAC > > WTPs? > > CTP's use of SNMP stems originally from managing legacy Local MAC > > WTPs. > > Can one easily extend it to Split MAC WTPs? > > The use of SNMP versus CAPWAP had been discussed earlier in this > > mailing list but I forgot what was the conclusion, if any? > > As others have stated, SNMP requires ASN.1, and this > therefore imposes significant per packet overhead to each > payload attached to a single message. Putting aside CPU > overhead this proposal alsowould create much larger packets, > and packet size efficiency is actually very important once we > start considering the use of CAPWAP over the air, for such > things as mesh networks (or 802.11s). > > While the IEEE has defined a MIB, history has shown that the > MIBs in question have been largely incomplete. The fact that > there is yet an AP MIB means that there is no MIB one could > actually use TODAY for CAPWAP. > So the end result is that every AP vendor out there has their > own enterprise specific MIB. Very few products actually make > use of the existing MIB, other than as there is work in > progress in 802.11v, but this is not expected to complete > until Ocotber 2008 (see Group Update/Timelines under > http://ieee802.org/11/index.html). So going down this path > would require CAPWAP to define the MIBs anyways, eliminating > the benefits of reusing IEEE work. > > So I would much prefer that we stick to the tried and true > method of AVPs, which has been very successful for such > protocols as RADIUS, etc. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 07 16:49:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED6r1-0003Lw-7p for capwap-archive@megatron.ietf.org; Wed, 07 Sep 2005 16:49:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21506 for ; Wed, 7 Sep 2005 16:49:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4007720607; Wed, 7 Sep 2005 16:49:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71AE1204DA; Wed, 7 Sep 2005 16:49:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37A3D204DA for ; Wed, 7 Sep 2005 16:48:33 -0400 (EDT) Received: from smtp107.mail.sc5.yahoo.com (smtp107.mail.sc5.yahoo.com [66.163.169.227]) by mail.frascone.com (Postfix) with SMTP id D2C9A20499 for ; Wed, 7 Sep 2005 16:48:31 -0400 (EDT) Received: (qmail 73499 invoked from network); 7 Sep 2005 20:48:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=H3ptTE3kK4e2j4Z4HgwziSDirugQjtBLjx9DZFp/vrzLez+mUsWIjn/mcH+9KA6t/COC6ljjbQnQ8VPCDTaNqdO8UeQHtwEDo8id1e5j7+8ZTykLpy9uj5stzJpZY356coCS4s8ItvQqpZlW4AaBwzPL7qy19uzJ9hWDgLve69U= ; Received: from unknown (HELO ?192.168.1.102?) (behcetsarikaya@24.71.246.253 with plain) by smtp107.mail.sc5.yahoo.com with SMTP; 7 Sep 2005 20:48:27 -0000 Message-ID: <431F521A.7000102@yahoo.com> From: Behcet Sarikaya Reply-To: sarikaya@ieee.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: capwap@frascone.com Subject: Re: [Capwap] CAPWAP eval team - CTP evaluation References: <1652EBA28502ED4393B9BC9B8A4B601329BDFF@mism121a.toronto.chantrynetworks.com> In-Reply-To: <1652EBA28502ED4393B9BC9B8A4B601329BDFF@mism121a.toronto.chantrynetworks.com> Content-Type: multipart/alternative; boundary="------------050208010601000701080804" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 07 Sep 2005 13:48:26 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------050208010601000701080804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Again with my eval team member hat off, I would like more people to chip in, the designers of the other candidate protocols, WG members alike. Regards, --behcet Michael Montemurro wrote: >There are a number of reasons why the CTP protocol relies used SNMP payload >(not SNMP) for WTP configuration: > >1) Protocol Administration: The IEEE defines MIB configuration elements with >every amendment to the standard. If the CAPWAP working group adopts an >approach of using the SNMP mib definition for configuration of Access >Points, it means that the group does not have rev TLV's every time there is >a new amendment to the standard. If the MIB does not compile, CAPWAP should >go back to the IEEE to fix the MIB. > >Using existing MIB definitions for configuration also allows the CAPWAP >working group to apply the protocol to other wireless technologies without >having to derive new configuration elements. > >Contrary to Pat's statement, I would say that most vendors that supply an >SNMP mib with their Access Point use the 802.11 MIB as a basis. Also, I very >much doubt that the CAPWAP working group would make use of 802.11 amendments >prior to them becoming a standard. > >Also, if TLV's are adopted for configuration, the CAPWAP working group is >likely going to need to rely on the 802.11 MIB to derive new TLV's. > >2) Ease of Implementation: Most, if not all enterprise class AP's have an >SNMP agent. If CAPWAP relies on SNMP payload for configuration, the existing >SNMP agent on the WTP can be used for CAPWAP implementation. > >We have had a lot of success in using this mechanism to port our protocol >across different AP hardware/software platforms. We also have not seen any >problems with regard to processor overhead or network overhead. The size of >a large configuration packet is approximately around 7k, which would not >represent significant network overhead. > >This protocol is different from RADIUS and other IETF protocols in that it >is based on work done by another standards body. However if the SNMP >definition has already been done by another standards body, why not use it? > >Cheers, > > Mike > > > >>-----Original Message----- >>From: capwap-admin@frascone.com >>[mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) >>Sent: September 7, 2005 12:30 PM >>To: sarikaya@ieee.org; capwap@frascone.com >>Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation >> >> >> >>>With my eval team member hat off, >>>can I ask how appropriate/feasible/good SNMP would be for Split MAC >>>WTPs? >>>CTP's use of SNMP stems originally from managing legacy Local MAC >>>WTPs. >>>Can one easily extend it to Split MAC WTPs? >>>The use of SNMP versus CAPWAP had been discussed earlier in this >>>mailing list but I forgot what was the conclusion, if any? >>> >>> >>As others have stated, SNMP requires ASN.1, and this >>therefore imposes significant per packet overhead to each >>payload attached to a single message. Putting aside CPU >>overhead this proposal alsowould create much larger packets, >>and packet size efficiency is actually very important once we >>start considering the use of CAPWAP over the air, for such >>things as mesh networks (or 802.11s). >> >>While the IEEE has defined a MIB, history has shown that the >>MIBs in question have been largely incomplete. The fact that >>there is yet an AP MIB means that there is no MIB one could >>actually use TODAY for CAPWAP. >>So the end result is that every AP vendor out there has their >>own enterprise specific MIB. Very few products actually make >>use of the existing MIB, other than as there is work in >>progress in 802.11v, but this is not expected to complete >>until Ocotber 2008 (see Group Update/Timelines under >>http://ieee802.org/11/index.html). So going down this path >>would require CAPWAP to define the MIBs anyways, eliminating >>the benefits of reusing IEEE work. >> >>So I would much prefer that we stick to the tried and true >>method of AVPs, which has been very successful for such >>protocols as RADIUS, etc. >> >> >>Pat Calhoun >>CTO, Wireless Networking Business Unit >>Cisco Systems >>_______________________________________________ >>Capwap mailing list >>Capwap@frascone.com >>http://mail.frascone.com/mailman/listinfo/capwap >> >> >> > > > --------------050208010601000701080804 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Again with my eval team member hat off, I would like more people to chip in, the designers of the other candidate protocols, WG members alike.

Regards,
--behcet

Michael Montemurro wrote:
There are a number of reasons why the CTP protocol relies used SNMP payload
(not SNMP) for WTP configuration:

1) Protocol Administration: The IEEE defines MIB configuration elements with
every amendment to the standard. If the CAPWAP working group adopts an
approach of using the SNMP mib definition for configuration of Access
Points, it means that the group does not have rev TLV's every time there is
a new amendment to the standard. If the MIB does not compile, CAPWAP should
go back to the IEEE to fix the MIB.

Using existing MIB definitions for configuration also allows the CAPWAP
working group to apply the protocol to other wireless technologies without
having to derive new configuration elements.

Contrary to Pat's statement, I would say that most vendors that supply an
SNMP mib with their Access Point use the 802.11 MIB as a basis. Also, I very
much doubt that the CAPWAP working group would make use of 802.11 amendments
prior to them becoming a standard.

Also, if TLV's are adopted for configuration, the CAPWAP working group is
likely going to need to rely on the 802.11 MIB to derive new TLV's.

2) Ease of Implementation: Most, if not all enterprise class AP's have an
SNMP agent. If CAPWAP relies on SNMP payload for configuration, the existing
SNMP agent on the WTP can be used for CAPWAP implementation. 

We have had a lot of success in using this mechanism to port our protocol
across different AP hardware/software platforms. We also have not seen any
problems with regard to processor overhead or network overhead. The size of
a large configuration packet is approximately around 7k, which would not
represent significant network overhead.

This protocol is different from RADIUS and other IETF protocols in that it
is based on work done by another standards body. However if the SNMP
definition has already been done by another standards body, why not use it?

Cheers,

	Mike

  
-----Original Message-----
From: capwap-admin@frascone.com 
[mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou)
Sent: September 7, 2005 12:30 PM
To: sarikaya@ieee.org; capwap@frascone.com
Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation

    
With my eval team member hat off,
can I ask how appropriate/feasible/good SNMP would be for Split MAC 
WTPs?
CTP's use of SNMP stems originally from managing legacy Local MAC 
WTPs.
Can one easily extend it to Split MAC WTPs?
The use of SNMP versus CAPWAP had been discussed earlier in this 
mailing list but I forgot what was the conclusion, if any?
      
As others have stated, SNMP requires ASN.1, and this 
therefore imposes significant per packet overhead to each 
payload attached to a single message. Putting aside CPU 
overhead this proposal alsowould create much larger packets, 
and packet size efficiency is actually very important once we 
start considering the use of CAPWAP over the air, for such 
things as mesh networks (or 802.11s).

While the IEEE has defined a MIB, history has shown that the 
MIBs in question have been largely incomplete. The fact that 
there is yet an AP MIB means that there is no MIB one could 
actually use TODAY for CAPWAP.
So the end result is that every AP vendor out there has their 
own enterprise specific MIB. Very few products actually make 
use of the existing MIB, other than as there is work in 
progress in 802.11v, but this is not expected to complete 
until Ocotber 2008 (see Group Update/Timelines under 
http://ieee802.org/11/index.html). So going down this path 
would require CAPWAP to define the MIBs anyways, eliminating 
the benefits of reusing IEEE work.

So I would much prefer that we stick to the tried and true 
method of AVPs, which has been very successful for such 
protocols as RADIUS, etc.


Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.frascone.com/mailman/listinfo/capwap
--------------050208010601000701080804-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 07 17:29:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED7Tk-0005hK-5n for capwap-archive@megatron.ietf.org; Wed, 07 Sep 2005 17:29:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23034 for ; Wed, 7 Sep 2005 17:29:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2C832064B; Wed, 7 Sep 2005 17:29:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 69E052053F; Wed, 7 Sep 2005 17:29:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C1FA92053F for ; Wed, 7 Sep 2005 17:28:34 -0400 (EDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by mail.frascone.com (Postfix) with ESMTP id 6B8FB204DA for ; Wed, 7 Sep 2005 17:28:31 -0400 (EDT) Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j87LSPGQ011069; Wed, 7 Sep 2005 21:28:25 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j87LRWTm023628; Wed, 7 Sep 2005 21:28:25 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005090714282524233 ; Wed, 07 Sep 2005 14:28:25 -0700 Received: from orsmsx404.amr.corp.intel.com ([192.168.65.44]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Sep 2005 14:28:25 -0700 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] In-band/out-of-band firmware download Message-ID: <0604335B7764D141945E20215310596005C52B6C@orsmsx404.amr.corp.intel.com> Thread-Topic: [Capwap] In-band/out-of-band firmware download thread-index: AcWy6ajZ/TympsVcRj+fGzoJAtk0MgA2xqLQAAp6QMA= From: "Sood, Kapil" To: "Pat Calhoun (pacalhou)" , "Michael Montemurro" , X-OriginalArrivalTime: 07 Sep 2005 21:28:25.0544 (UTC) FILETIME=[14B02480:01C5B3F3] X-Scanned-By: MIMEDefang 2.52 on 10.7.209.17 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 7 Sep 2005 14:28:24 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The difference may lie in the "purpose" and properties of the existing SA, and the implicit/explicit Access Control that goes with that protected channel. Best Regards, =20 Kapil. 503.264.3759 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of > Pat Calhoun (pacalhou) > Sent: Wednesday, September 07, 2005 8:58 AM > To: Michael Montemurro; capwap@frascone.com > Subject: RE: [Capwap] In-band/out-of-band firmware download >=20 > Not clear to me why you state that out of band is more robust. >=20 > I think that being able to piggy back from the existing security > association, and encryption channel, between the WTP and the AC has lots > of value. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 >=20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Michael Montemurro > > Sent: Tuesday, September 06, 2005 6:46 AM > > To: capwap@frascone.com > > Subject: [Capwap] In-band/out-of-band firmware download > > > > One implicit technical issue that I believe has come out of > > the regulatory discussion is regading firmware download. > > There seems to be two different mechanisms that are proposed > > for firmware download to the WTP: one uses the control > > channel between the AC and the WTP (I call that an in-band > > mechanism) and the other uses a separate protocol, > > independent of the control channel. > > > > An in-band mechanism provides a simpler mechanism for > > monitoring the progress of the firmware download and > > simplified state management. An out-of-band mechanism relies > > on other protocols (sftp, ftp, tftp), which would likely > > provide a more robust mechanism for download, but perhaps a > > slightly more compicated state machine. > > > > What is the feeling of the group on how firmware download should work? > > > > Cheers, > > > > Mike > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 07 17:59:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED7wl-0005Ve-FF for capwap-archive@megatron.ietf.org; Wed, 07 Sep 2005 17:59:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24285 for ; Wed, 7 Sep 2005 17:59:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 24E1B2064C; Wed, 7 Sep 2005 17:59:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5AD2720565; Wed, 7 Sep 2005 17:59:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D592220565 for ; Wed, 7 Sep 2005 17:58:30 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id C634A2053F for ; Wed, 7 Sep 2005 17:58:28 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 07 Sep 2005 14:58:28 -0700 X-IronPort-AV: i="3.96,177,1122879600"; d="scan'208"; a="210280566:sNHT32747352" 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 j87LvcKo024045; Wed, 7 Sep 2005 14:58:22 -0700 (PDT) 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, 7 Sep 2005 14:58:22 -0700 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] CAPWAP eval team - CTP evaluation Message-ID: <4FF84B0BC277FF45AA27FE969DD956A29C43BF@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] CAPWAP eval team - CTP evaluation Thread-Index: AcWz5Y5NUlBpglzCRUugrBmQazctvQADyTuA From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , , X-OriginalArrivalTime: 07 Sep 2005 21:58:22.0940 (UTC) FILETIME=[440501C0:01C5B3F7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 7 Sep 2005 14:58:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable See my comments below. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > There are a number of reasons why the CTP protocol relies=20 > used SNMP payload (not SNMP) for WTP configuration: >=20 > 1) Protocol Administration: The IEEE defines MIB=20 > configuration elements with every amendment to the standard.=20 > If the CAPWAP working group adopts an approach of using the=20 > SNMP mib definition for configuration of Access Points, it=20 > means that the group does not have rev TLV's every time there=20 > is a new amendment to the standard. If the MIB does not=20 > compile, CAPWAP should go back to the IEEE to fix the MIB. Or alternatively, it could do everything within the WG, which would eliminate the cross-SDO communication, hence reduce time to RFC.=20 >=20 > Using existing MIB definitions for configuration also allows=20 > the CAPWAP working group to apply the protocol to other=20 > wireless technologies without having to derive new=20 > configuration elements. >=20 > Contrary to Pat's statement, I would say that most vendors=20 > that supply an SNMP mib with their Access Point use the=20 > 802.11 MIB as a basis. Also, I very much doubt that the=20 > CAPWAP working group would make use of 802.11 amendments=20 > prior to them becoming a standard. The current 802.11 MIB is designed for a STA, and does not even allow for such things as multiple SSIDs. The lack of such a MIB was instrumental to the creation of TGv, for which I am chair. Feel free to look at the TG information on http://ieee802.org/11/index.html. >=20 > Also, if TLV's are adopted for configuration, the CAPWAP=20 > working group is likely going to need to rely on the 802.11=20 > MIB to derive new TLV's. Ok, sure. However, mind you that it's not clear to me that the MIBs created by the IEEE are really relevant for this working group. The reason for this statement is that the IEEE considers everything to be a STA. In fact, the IEEE still considers an AP to be a single autonomous device, so the architectures being adopted by CAPWAP have additional configuration elements that are never specified by the IEEE (because, again, they consider this to be a closed system). So what they would consider to be parameters in some API, we consider to be a protocol. >=20 > 2) Ease of Implementation: Most, if not all enterprise class=20 > AP's have an SNMP agent. If CAPWAP relies on SNMP payload for=20 > configuration, the existing SNMP agent on the WTP can be used=20 > for CAPWAP implementation.=20 >=20 > We have had a lot of success in using this mechanism to port=20 > our protocol across different AP hardware/software platforms.=20 > We also have not seen any problems with regard to processor=20 > overhead or network overhead. The size of a large=20 > configuration packet is approximately around 7k, which would=20 > not represent significant network overhead. Versus less than an Ethernet MTU in LWAPP. Over the air, 7K requires=20 5 individual transmissions, plus PIFS, so when running CAPWAP over the air, it actually is significant. >=20 > This protocol is different from RADIUS and other IETF=20 > protocols in that it is based on work done by another=20 > standards body. However if the SNMP definition has already=20 > been done by another standards body, why not use it? If you can show me a MIB done by the IEEE (or IETF for that matter) that is suitable for CAPWAP, then I will agree ;-) _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From ringel@email.msn.com Thu Sep 08 09:01:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDM2E-000473-Kn; Thu, 08 Sep 2005 09:01:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18082; Thu, 8 Sep 2005 09:01:42 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDM5Y-00039C-Td; Thu, 08 Sep 2005 09:05:14 -0400 Received: from pool-70-23-83-183.ny325.east.verizon.net ([70.23.83.183]) by mx2.foretec.com with smtp (Exim 4.24) id 1EDM28-0004o2-JZ; Thu, 08 Sep 2005 09:01:41 -0400 Received: from 70.23.83.183 ([70.23.83.183]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id jLg2Mz75 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=YES check=NO) for ; Thu, 08 Sep 2005 05:58:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: RHVFO== X-IronPort-AV: i="3.96,160,9188710872"; d="scan'556"; a="6897200:sNHT117027670" Message-Id: <6.0.1.57.0.77150366215541.98206064@knowledgeable.msn.com> X-Sender: ringel@email.msn.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.91 Date: Thu, 08 Sep 2005 05:58:17 -0800 To: bridge-mib-admin@ietf.org, capwap-archive@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org From: "Lelia Harding" Subject: Pre-approved Application #18449168 Thu, 08 Sep 2005 05:58:17 -0800 Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_RPTATT28319516.Exime" X-Spam-Score: 2.0 (++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 --=====================_RPTATT28319516.Exime Content-Type: multipart/alternative; boundary="=====================_RPTATT88290979.Exime" --=====================_RPTATT88290979.Exime Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 7bit postorder is athlete deceive indium and curlew pheasant but dignity lancashire a chamberlain cloven chinamen, fundraise speedboat and cinema alluvium, amplitude troika countersunk try western davenport but sabina brisbane is coronate aerospace whither and beryl prestidigitate but compile --=====================_RPTATT88290979.Exime Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

you'd it's compose the horseflesh may idiotic a bract not draftsperson or neonate on memorial on spectroscope and sacrilegious a stoppage in vendible try focus in pitilessly , ancillary on pomegranate it conjecture be miss may abdominal it leech some quill ! limp , tempera but vaduz the vibrate or tenth be aggregate in breach not martin a aphelion , plush be ptolemy ! tutelage and alex it's new or parke be.
Not, go here http://www.l8mort.net/book
--=====================_RPTATT88290979.Exime-- --=====================_RPTATT28319516.Exime Content-Type: image/gif; name="minot.58.gif"; x-mac-type="7A860556"; x-mac-creator="8A739116" Content-ID: <3.0.0.40.0.88314043134946.42242412@coextensive.yahoo.com.5> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="minot.58.gif" Content-Transfer-Encoding: base64 R0lGODlhTgJRAZEAAP///wAAAP8AAAAAmSH5BAAAAAAALAAAAABOAlEBAAL/RIB4yb3Wopy0 2ouz3rz7D4biSJbmiabqymaPgj1vS9f2jef6zvf+r5u9AkRhQlgEKpfMpvMJjUqDjiNjaM3C ptyu9wsOi8eOYnKLhqSx5Lb7DY/L40aFma1ez/f8vv8PKFKXFyFzdRiYqLjI2Ng1OINIiOdY aXmJmQkCKZlHGakZKjpKCjhocKaFRFRV6voKGxsKKltre4sLRpvL2+v7CxwsPExcbHyMnKy8 zNzs/AwdLT1NXW19jZ2tvc3d7f0NHi4+Tl5ufo6err7O3u7+Dh8vP09fb3+Pn6+/z9/v/w8w oMCBBAsaPIgwocKFDBs6fAgxosSJFCtavIgxY59T/4RiWNhFAWQJkR9b/aFl6AtJDStrtHTh 0cZLQWFmjjxEKeYJmx54dlJE0icPoRKI7txhdENSljWHWkl5JFUZVjCorlrVcepUI6nMRKV6 BaxXNAekoio74dRYPSG7qnoK1tPWj2aTDDFbqO7ZuVo84e0oQ+onVGnDin1bFKfYrnoXx7UT +DHcvYa5lmWMtrLWqyEJf418V7IJQ1AnFQ7bCU/gzmRTQx2MGHDU2KJlszV9esvr2a1vZ+37 uvSuT7tj406MSLXrCsJ7/55U3Hdc2HLb2nEOPTXv26uBp1Xb9zgK0t7DhwdvfDhy6ebLm8Te PDf1nKwhoJ3v/nkh9/RzH/9Xnt9+8OUnUnz2HegfgOxp1x5I0VG34HoQolRSGuKNJ9dVtXEU mlvtWRhhdZo1aJKC+hkoon6QkZcZd8DdQddh6cWI34wfOmdif5Iod199/1U23VaPCcYcbQwS mJeMa8C4Hl+AMalCiy2C2KRtVF74U4ilpQgKJzYWhh6WOz6FoIu+VchlgCUemWOWVdR4poA/ 9pjgmDdyJF+ROB4ZoogQ+mikm1Fm+B6gYb6nnpziodiflwN2FqaOc5b5Y5x1mnnlonY+mmlV bPIp4Zh0NtmmfyoaJ2d0F064qZiKYtophlnqyOGn1+WpJX8KOuqng1b2Wl+QFu4K6o7BqanK XV//dhfrlLtKymmKipZ6Jpy+7hmgatomWyyIzB6aAp5nDafksHWx4uCQeiUb2ZOhfblXgUWd O2WSlfJ33l+GQeesvl+ZRi9W7wI67maCvjjkjZpC9lmhBWv1b6hLJrwvwwLvy5mpFke8osP1 yEvKUj6I7A1PJD8E7amJpMzFydew7KpG39V2qyZrjUHzOjfTKHPPPv8MdNBCD0100UYfjXTS Si/NdNNOPw111FJPTXXVVl+NddZab811115/DXbYYo9Ndtlmn4122mqvzXbbbr8Nd9xyz013 3Ul3SYLLOk1BlE/pQqH3BST7Dbe4PVHxyCaHa8xE4GjSZDdME4MLVyRr/6nl72WWB/xmznjd nDHHoNP73OWNkStsaxs6+eDnjlH4+ogP55k5opxPxnFFqv65HWy8osQogVvCGzy2+NY87XI+ Gug5g8VZyxyryJI1/LDHU7/mRc7ySeGdxF8KK+9XUiut9fAi2q2t2JEqapniXwt+zChmb2n5 jvtzKK2zesivvsSZDrqDBaxcd6iehubHvYOFT2ELO5CUoMQwhXWJSJ+hGQLTA8HZTfB++sif oHLSHMOh70OJipWr9Peq7mVKesu7XvxYVD6Jaax4gpuepwSIKo9JxIMkTCCZFIikKqUvfSgs lApP5MMWwop9bxnVSqp3niSiCVr1OiIUTdgQHv96JnncmtUHachC+t3rXlt6lhLrd71yMXGB adRTF/vUKl9FqnepysjmJGOX+MXLYztTzB1Dh0bXpa5jFYsgIf9VwkOacGd5bJaT1tdHwazO YKLzV5rcKLuNUWldNoycJxn4yVAugYOiLOUmSGnKVKpylaxspStfCctYynKWtKylLW+Jy1zq cpe87KUvfwnMYApzmMQspjGPicxkKnOZzGymM58JzWhKc5rURKYABGC0a8pMmw3g5hS82U1s pgCcTbimOSlATgCYU5wMWCc7J+DOCMSzneu8wDmd4E1w6vOd6dzBPBPwT4AGNKBc2GcF+qkI g3YBoQgVQUN9UM9+3lP/oAhQqDrfGU6KavSiG33oQyGKUXqKdKM9iCg784lRiZ40pFGwqAQ+ Cghu7nOiFV3pQWlaU5qidKQ5xak8B1pPgfpUqC5FKU4JWlOOwlOnLE2qU19q045GValQnShB kUrPow6Vp0bV5jzJidVwatWj2EznTknK1aYSVa09vWpQ28rPoLozpDD9g0ynatGG3jWtUuXr Rdl6V7zG9aZ91ehZc4rOsjbVq4NdKlr9+tTDkhWyf7WAZMU52adSdbN5BaxgNZvRj86UqY+l 7E8Vq9jCVpazccVsStmaiLdStbOJdWxkpzpb3P5UtS7drWb3elueLpWhqV3ra0sbXN7qNqOq /90sBg5rWdwWtbHOJSxoE0tcsH72urXtLnBz21zaCtcS2iUpdJnrW/D+dru2zS1Qrcva277X nlpdr2tNS9nLIne95oXtWrMKW+hOF8BbJTCAn1tgvbIXu5n9rn7529zqOqK8EJYwd9WLYQxn NsPohSpaZatgBGuYuuL1cIUf3N4M1/W740XvgPu7ARbvl6LE7S6Hfdvg+yZXxSQ+biYoHN8L WxjFJd7weVtsWhCrdcXF/es/Bbzc8LJ3wzymb2mNTN0gCzm9KrUyikc84yOP1MFTzvJ56xpT Hwc5wTrecWD9WmClWlW6nn0skHsbWjbnN8o7BvOWS2zhMZ8Vy8J9cf+g5TzoJaO2x4LGr6Dr jGjlwjjCojCrbOF6U0uPlbTGja6SN81glmoayMOlspPpeunRonrTAX5tfen76Vb3N7Btbius mSraS5/6tNqNM6a9W+v5spbMHSYImgvqXxMcux3LlqWYcdHsam4jrNKutrWvje1sa3vb3O62 t78N7nCLe9zkLre5z43udKt73exut7vfDe94y3ve9K63ve+N73zre9/87ve8MsgSVM5rO1t0 QQHzJvCe9FFIOXOJsligrhY0/AYTB9xiRpPwEUynbw/nQMXHQy6Pd/yUFid4XlDTg41LHAkr H2XGMd5yL6j8AzNf0R8bPjrM4BFKr3tJzcf/dUCUe4bn3wK46VB+cesI3eZCeiTQOw5wm0cS gFaheod8fnWkL2BDOe85kJz+741LMnNH36LY1bXwCmqIRhmEIIzc3vXLCD3pt7Jk1XNH96Hn /eMEp7vYa3Z3QwK+XQUP/M9NXobE967ovPm72UduL7tAnVnI8zvfB7/4ugOP5Zife3c8V3TO F1zxma950u0e+MdHT3OqrzzkLQ8asns+egOffeZdL/Ko4x7zh2+970ev+dorve+M7/zJkUf6 2qf++KM3PeUNfnupW7BAz7e8whGf9+Sr3vnRF771lb78pR/++7uvoO2/I3zpn7/3dFk60Nd/ LuaTH/h6Z/7wy9/z/7OTfvq0r3/TkX92jNEB81dA/Bd21XdwDSM4ZQckBkh8B1R86Gd8oBd8 X0d8DEd5P7d82ad9ABhyxkd//bd73Md02BeB7Dc7iJd+hReB98eBKth4W8d52YeClzeBVyd7 x0eDQUF9IIh898eCord/f3OD/beBMih+QpiE8Hd+K+iBw7d3NkGCLHh7HEh+Neg6MSCE8yeB Puh+ineE3UeFTriA3VeAH8iEX2h/8vd8IbiGF4eFMFiEP6h1c1h+dDiGnSdJgqeDCHiBlJGH 0FeFU5h6O2dIZzBz+kdzr3eCnzd5QAiGSBiDfhh9Nuh7EeeGwFd1lNh6FAiIhoiHzbcahP8o g0R4iURYiKW4hGmofg3IcDxjgoIkgAqYiQX4ipXoiAcYe3+0hqHYgBuEdsE4hG3BdRWodrRo dV/oiSVYh5D4dLT4fpk0M7P4f11ojAF4i12IjUYoiVI3InGnho5giU0wjpmoDeX4beioBOWo js7Qjv4mEybzjvBIj/Voj/eIj/moj/s4CuMIivyIMn6zOQBJEIZXirIYe+FIkPtgkBFEir24 kP1whmLYhL4YkfgwkV5IdBB5kR1kiz6YihzZkRj5kb/HheY4kh/TjSapihaZkvwQhh5IdQr5 kjVpkzeJkzmpkzvJkz3pkz8JlEEplENJlEVplEeJlEmplEvJlE3/6ZRPCZVRKZVTSZVVaZVX iZVZqZVbyZVd6ZVfCZZhKZZjSZZlaZZniZZpqZZryZZt6ZZvCZdxKZdzSZc9MAB3iZd3iQN6 eQJ4mQh8GQGACQCC+QGCSZh9mZcNcJgJQJh5OQCB+ZgMsJiDGZkIYJiOCZiY2ZiamTaT2QKe 6QGgOQeTKZqhWZk0kJmn6ZmXyZinSZmS6ZqwKZutSQGbOZttc5iOeQGYCZt+aZmJWZvAOQG6 SZm++ZvGeZylqZjE2ZulyZzFiZys2ZrCmZyVSZybGZ3PKQG2+ZvBSZu3+Zrd6Z3fKZ7b6ZrS iZvnaZ2xOZvGmZrkOZzrWQGXqZ7k+Z4a/+Cb6Ama91mc5amfkZmd9qmaAyqgAMqe8AmZ4xme 4yma6LmgCQqeyik23PmgELqg/Cmh5Wme4Omf8qmhu+mhHTqfIYqhBCqi8Qmf/ymgI8qiKPqh CeqcnDmdzEmh0EmdZUOh+0mivPmi5omcFlqhNpqa2mkB/HmhB3qiR5qiOwqZ7mmiSWqkQCql t9mgRLqcEYqkmlmfbpOjSKqkPRqkEKqjHBqmZYoBRhqlVwqlIfqlFcqXaPqkJdqiLrqhYDqd dvqgDqqmi5mhYNOlc5qmeNqmdfqipOmlRcqmgbqia0qlicqkS7qoZuqmbKqmk9qoc5qnWUqp koqjWyqpbyqngv8Kql6qp22qqHSqogo6pEn6pQHanxqaqoNKqKUKqR9Kq7D6pEBao2uTmzfq o9kJrKRqpbW6nD9KpKtJqcPanANKnQ7KozM6pAZarLEanMYqo5P6o5ZKqJn6rDWqpbHUp2EQ rlIwrlZ5qnBQrktwrl+prN7QrkOppfEqr/NKr/Vqr/eKr/mqr/vKr/3qr/8KsAErsANblwVr sAeLsAmrsAvLsA3rsA8LsRErsRNLsRVrsReLsRmrsRvLsR3rsR8LsiErsiNLsiVrsieLsimr sivLsi3rsi8LszErszNLszVrszeLszmrszvLsz3rsz8LtEErtENLtEVrtEeLtEmrtEv/ezUJ qDjTaEkS97MitDcO83JARLMcQjrQaB6AtEeZJHealDszq0UX5C3qM0gZ2HegpLJOu0TeM0LR IkYNdLOYk3M69HRBFyeXE7d8KLOUw0Uy9EE/oSonZLOA27eJWzpJhLhX67Bla0O1QhvbYj6F x7Yp67aKBIh+mxVe20iI1LXoAjGXy7QaR3GluwIwkzeom7pRy7qvC7uxK7uzS7u1a7u3i7u5 q7u7y7u967u/C7zBK7zDS7zFa7zHy49tJytKkbkqQbFU6xR0MLF4Yy5B8nfCYXdFgi7Wy3rS 2L3VQkERCzLcAQm7QxDNmIuXBHhBtD6P+zgmgimSUpJ+EiiBZau+Y/SwHcK+lrMp8utGD5Iv aSs8fCux1NtA/Fu/SBQs9Uy+NIS3CmvAcNJGcIsr9BxnDcw4DatF9kNHgfS/DPxGZCTB4stI j7RBXIJ6bgfCE0O3n6tIjsoxMIy8MTPDKzePuVsAADs= --=====================_RPTATT28319516.Exime-- From capwap-admin@frascone.com Thu Sep 08 09:05:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDM5a-0004fq-Po for capwap-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:05:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18330 for ; Thu, 8 Sep 2005 09:05:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A299120658; Thu, 8 Sep 2005 09:05:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD45620649; Thu, 8 Sep 2005 09:05:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A5B5020649 for ; Thu, 8 Sep 2005 09:04:26 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 6AE7B20623 for ; Thu, 8 Sep 2005 09:04:24 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Thu, 08 Sep 2005 09:05:34 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id B45D924FBF; Thu, 8 Sep 2005 09:04:49 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Sep 2005 08:58:54 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601329BE8A@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: "Pat Calhoun (pacalhou)" , sarikaya@ieee.org, capwap@frascone.com Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 8 Sep 2005 09:04:11 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Pat, See my comments below: > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: September 7, 2005 5:58 PM > To: Michael Montemurro; sarikaya@ieee.org; capwap@frascone.com > Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation > > See my comments below. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > There are a number of reasons why the CTP protocol relies used SNMP > > payload (not SNMP) for WTP configuration: > > > > 1) Protocol Administration: The IEEE defines MIB configuration > > elements with every amendment to the standard. > > If the CAPWAP working group adopts an approach of using the > SNMP mib > > definition for configuration of Access Points, it means > that the group > > does not have rev TLV's every time there is a new amendment to the > > standard. If the MIB does not compile, CAPWAP should go back to the > > IEEE to fix the MIB. > > Or alternatively, it could do everything within the WG, which > would eliminate the cross-SDO communication, hence reduce > time to RFC. > CAPWAP is inherently based on other wireless standards. Unless this WG is planning on defining their own wireless MAC/PHY, it will depend on other SDO's for standards. You still have to look at configuration elements that happen to be defined in the MIB to derive your TLV's. > > > > Using existing MIB definitions for configuration also allows the > > CAPWAP working group to apply the protocol to other wireless > > technologies without having to derive new configuration elements. > > > > Contrary to Pat's statement, I would say that most vendors > that supply > > an SNMP mib with their Access Point use the > > 802.11 MIB as a basis. Also, I very much doubt that the > CAPWAP working > > group would make use of 802.11 amendments prior to them becoming a > > standard. > > The current 802.11 MIB is designed for a STA, and does not > even allow for such things as multiple SSIDs. The lack of > such a MIB was instrumental to the creation of TGv, for which > I am chair. Feel free to look at the TG information on > http://ieee802.org/11/index.html. > There is no standard for multiple SSID's. There has been discussion around defining a "multi-BSS" standard in 802.11 for about the last 2 years. I'm glad that finally the IEEE has decided to take that task. However, I thought it was Tgu that was defining "multi-BSS". > > > > Also, if TLV's are adopted for configuration, the CAPWAP > working group > > is likely going to need to rely on the 802.11 MIB to derive > new TLV's. > > Ok, sure. However, mind you that it's not clear to me that > the MIBs created by the IEEE are really relevant for this > working group. The reason for this statement is that the IEEE > considers everything to be a STA. In fact, the IEEE still > considers an AP to be a single autonomous device, so the > architectures being adopted by CAPWAP have additional > configuration elements that are never specified by the IEEE > (because, again, they consider this to be a closed system). > So what they would consider to be parameters in some API, we > consider to be a protocol. > You keep stating that the IEEE considers everything a STA and yet, the only example for a feature that is missing is multi-SSID, which isn't a standard. I don't know of an enterprise class AP that doesn't have a MIB based on the 802.11 MIB. Also, I would like to understand what is missing from the 802.11 MIB that would prevent it from being used by the CAPWAP WG. > > > > 2) Ease of Implementation: Most, if not all enterprise > class AP's have > > an SNMP agent. If CAPWAP relies on SNMP payload for > configuration, the > > existing SNMP agent on the WTP can be used for CAPWAP > implementation. > > > > We have had a lot of success in using this mechanism to port our > > protocol across different AP hardware/software platforms. > > We also have not seen any problems with regard to processor > overhead > > or network overhead. The size of a large configuration packet is > > approximately around 7k, which would not represent > significant network > > overhead. > > Versus less than an Ethernet MTU in LWAPP. Over the air, 7K requires > 5 individual transmissions, plus PIFS, so when running CAPWAP > over the air, it actually is significant. > The amount of time you are talking about a time, which over the aire, is actually less than 9 ms. When you start taking a look at discovery and authentication, this timing is insignificant. > > > > This protocol is different from RADIUS and other IETF protocols in > > that it is based on work done by another standards body. However if > > the SNMP definition has already been done by another > standards body, > > why not use it? > > If you can show me a MIB done by the IEEE (or IETF for that > matter) that is suitable for CAPWAP, then I will agree ;-) > It depends how you define suitable? ;-) Cheers, Mike _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 08 09:56:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMsx-0000Cn-JE for capwap-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:56:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20407 for ; Thu, 8 Sep 2005 09:56:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B6532065B; Thu, 8 Sep 2005 09:56:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1893320649; Thu, 8 Sep 2005 09:56:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2453E20649 for ; Thu, 8 Sep 2005 09:55:32 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id DE643201F6 for ; Thu, 8 Sep 2005 09:55:29 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2005 06:55:29 -0700 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 j88DstKa020898; Thu, 8 Sep 2005 06:55:23 -0700 (PDT) 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); Thu, 8 Sep 2005 06:55:19 -0700 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] CAPWAP eval team - CTP evaluation Message-ID: <4FF84B0BC277FF45AA27FE969DD956A29C453E@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] CAPWAP eval team - CTP evaluation Thread-Index: AcW0ddy9QjMzGAuGSiiTihEbqZhplwABhEcg From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , , X-OriginalArrivalTime: 08 Sep 2005 13:55:19.0498 (UTC) FILETIME=[F2F47AA0:01C5B47C] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 8 Sep 2005 06:55:18 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable > CAPWAP is inherently based on other wireless standards.=20 > Unless this WG is planning on defining their own wireless=20 > MAC/PHY, it will depend on other SDO's for standards. You=20 > still have to look at configuration elements that happen to=20 > be defined in the MIB to derive your TLV's. Agreed. However, I believe that the assumption is that CAPWAP picks up a completed MAC/PHY and then adapts the CAPWAP protocol to it. If CAPWAP then required that they send a liason to the appropriate SDO to further expand their MIBs for our use, then I would argue that this would significantly increase our time to delivery. We cannot assume that other SDOs understand our problem space, and certainly are not designing their protocols to satisfy our needs. > There is no standard for multiple SSID's. There has been=20 > discussion around defining a "multi-BSS" standard in 802.11=20 > for about the last 2 years. I'm glad that finally the IEEE=20 > has decided to take that task. However, I thought it was Tgu=20 > that was defining "multi-BSS". TGv is creating the MIB. TGu is looking at what multiple-BSS means. The actual MIB is what we care about here because we are talking about WTP configuration, not what the user sees over the air. > You keep stating that the IEEE considers everything a STA and=20 > yet, the only example for a feature that is missing is=20 > multi-SSID, which isn't a standard. > I don't know of an enterprise class AP that doesn't have a=20 > MIB based on the > 802.11 MIB. Also, I would like to understand what is missing=20 > from the 802.11 MIB that would prevent it from being used by=20 > the CAPWAP WG. Show me the MIB that allows one to retrieve the list of STAs and association state from an AP? Given that CAPWAP supports encryption in the WTP, show me the MIB that allows us to push the PTK/GTK from the AC to the WTP. etc, etc. > The amount of time you are talking about a time, which over=20 > the aire, is actually less than 9 ms. When you start taking a=20 > look at discovery and authentication, this timing is insignificant. I think we will have to agree to disagree. When you take those 9ms, and then you run it on a mesh that consists of 4 hops - things add up. Keep in mind these types of messages are generated when users come and go, etc. So it's more than just configuring the WTP, so efficiency is required here. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 08 10:26:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNM0-0000JC-J3 for capwap-archive@megatron.ietf.org; Thu, 08 Sep 2005 10:26:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22818 for ; Thu, 8 Sep 2005 10:26:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C25CC20665; Thu, 8 Sep 2005 10:26:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1BC902064A; Thu, 8 Sep 2005 10:26:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 120C12064A for ; Thu, 8 Sep 2005 10:25:21 -0400 (EDT) Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 61DAC20649 for ; Thu, 8 Sep 2005 10:25:19 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Thu, 08 Sep 2005 10:26:54 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 4121324FAC; Thu, 8 Sep 2005 10:26:09 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Sep 2005 10:20:14 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601329BECA@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: "Pat Calhoun (pacalhou)" , sarikaya@ieee.org, capwap@frascone.com Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 8 Sep 2005 10:25:31 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Pat, I've inserted my comments below. Although I enjoy debating this topic with you, it would be nice to hear other opinions from the WG on this topic. However I think there is a misunderstanding on how we could make use of SNMP. SNMP is only used for two functions: passing "configuration information" from the AC down to the WTP; and passing statistics from the WTP to the AC. The purpose is to make use of the OID's defined by the IEEE, and the SNMP agent that exists on most, if not all, enterprise class AP's. The protocol still needs to define control messages that allow the AC and the WTP to exchange state information on connections. Cheers, Mike > > > CAPWAP is inherently based on other wireless standards. > > Unless this WG is planning on defining their own wireless > MAC/PHY, it > > will depend on other SDO's for standards. You still have to look at > > configuration elements that happen to be defined in the MIB > to derive > > your TLV's. > > Agreed. However, I believe that the assumption is that CAPWAP > picks up a completed MAC/PHY and then adapts the CAPWAP > protocol to it. If CAPWAP then required that they send a > liason to the appropriate SDO to further expand their MIBs > for our use, then I would argue that this would significantly > increase our time to delivery. We cannot assume that other > SDOs understand our problem space, and certainly are not > designing their protocols to satisfy our needs. > The SDO provides enough information so that you could configure the MAC/PHY through SNMP OIDs. In CTP, we use the SNMP mib to push configuration information down to the WTP. It makes it easy to format the configuration message. > > There is no standard for multiple SSID's. There has been discussion > > around defining a "multi-BSS" standard in 802.11 for about > the last 2 > > years. I'm glad that finally the IEEE has decided to take > that task. > > However, I thought it was Tgu that was defining "multi-BSS". > > TGv is creating the MIB. TGu is looking at what multiple-BSS > means. The actual MIB is what we care about here because we > are talking about WTP configuration, not what the user sees > over the air. > In your LWAPP model, I assume we would need the WTP configuration to create configuration TLV's. In the CTP model, we would use the OID's that TGv defines to specify the configuration of the WTP. In the CTP case, you don't need to rev the specification for configuration in the AC-WTP protocol. > > You keep stating that the IEEE considers everything a STA > and yet, the > > only example for a feature that is missing is multi-SSID, > which isn't > > a standard. > > I don't know of an enterprise class AP that doesn't have a > MIB based > > on the > > 802.11 MIB. Also, I would like to understand what is > missing from the > > 802.11 MIB that would prevent it from being used by the CAPWAP WG. > Show me the MIB that allows one to retrieve the list of STAs > and association state from an AP? Given that CAPWAP supports > encryption in the WTP, show me the MIB that allows us to push > the PTK/GTK from the AC to the WTP. etc, etc. > The two examples you give relate to state information on the WTP, not configuration. I believe that the CAPWAP protocol needs to define messages that allow the WTP and the AP to share connection state information. The CAPWAP protocol needs to define messages that allow the WTP and the AC to ensure state information. There needs to be a message that lets the AC know that a STA has associated. There also needs to be a messages for keying information to be passed from the AC to the WTP. > > The amount of time you are talking about a time, which over > the aire, > > is actually less than 9 ms. When you start taking a look at > discovery > > and authentication, this timing is insignificant. > I think we will have to agree to disagree. When you take > those 9ms, and then you run it on a mesh that consists of 4 > hops - things add up. Keep in mind these types of messages > are generated when users come and go, etc. So it's more than > just configuring the WTP, so efficiency is required here. > No. That is not how we proposed using SNMP. CTP only uses SNMP for configuration elements that are passed from the WTP to the AC. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 08 11:07:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNzh-0001Jz-Ir for capwap-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:07:17 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25231 for ; Thu, 8 Sep 2005 11:07:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 429FA20669; Thu, 8 Sep 2005 11:07:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6780520649; Thu, 8 Sep 2005 11:07:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF72920649 for ; Thu, 8 Sep 2005 11:06:16 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 61AF81FFF2 for ; Thu, 8 Sep 2005 11:06:08 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Sep 2005 08:06:07 -0700 X-IronPort-AV: i="3.96,179,1122879600"; d="scan'208"; a="339864550:sNHT43685996" 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 j88F5pKM013365; Thu, 8 Sep 2005 08:06:03 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 08:05:53 -0700 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] CAPWAP eval team - CTP evaluation Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC860E18@xmb-sjc-237.amer.cisco.com> Thread-Topic: [Capwap] CAPWAP eval team - CTP evaluation Thread-Index: AcW0gVsKYIMtVnSORRaReq2h3GrYLAAAnidg From: "Bob O'Hara (boohara)" To: "Michael Montemurro" , "Pat Calhoun (pacalhou)" , , X-OriginalArrivalTime: 08 Sep 2005 15:05:53.0770 (UTC) FILETIME=[CEC71CA0:01C5B486] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 8 Sep 2005 08:05:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Mike, I agree that other opinions would be interesting to hear. Unfortunately, it has been quite some time since anyone outside a very small group of posters, including the authors of the various proposals, has felt the need to offer an opinion or an insight into what they want out of CAPWAP. =20 Perhaps all that the vast majority that attend the WG meetings want to see is a little entertainment. I hope that is not the case. In any case, a few comments, below. -Bob =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Michael Montemurro Sent: Thursday, September 08, 2005 7:26 AM To: Pat Calhoun (pacalhou); sarikaya@ieee.org; capwap@frascone.com Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation Pat, I've inserted my comments below. Although I enjoy debating this topic with you, it would be nice to hear other opinions from the WG on this topic.=20 However I think there is a misunderstanding on how we could make use of SNMP. SNMP is only used for two functions: passing "configuration information" from the AC down to the WTP; and passing statistics from the WTP to the AC. The purpose is to make use of the OID's defined by the IEEE, and the SNMP agent that exists on most, if not all, enterprise class AP's. The protocol still needs to define control messages that allow the AC and the WTP to exchange state information on connections. Bob>> There is not necessarily an SNMP agent in all of the WTP configurations under discussion. Certainly there might be an agent in a local MAC (local AP) WTP. However, it is highly speculative to say there is also an agent present in a split MAC (split AP) or a remote MAC (remote AP). These also represent "enterprise class" APs. I know of at least two implementations of the Split MAC (split AP) that do not have an agent present. More, below. Cheers, Mike >=20 > > CAPWAP is inherently based on other wireless standards.=20 > > Unless this WG is planning on defining their own wireless=20 > MAC/PHY, it=20 > > will depend on other SDO's for standards. You still have to look at=20 > > configuration elements that happen to be defined in the MIB=20 > to derive=20 > > your TLV's. >=20 > Agreed. However, I believe that the assumption is that CAPWAP=20 > picks up a completed MAC/PHY and then adapts the CAPWAP=20 > protocol to it. If CAPWAP then required that they send a=20 > liason to the appropriate SDO to further expand their MIBs=20 > for our use, then I would argue that this would significantly=20 > increase our time to delivery. We cannot assume that other=20 > SDOs understand our problem space, and certainly are not=20 > designing their protocols to satisfy our needs. > The SDO provides enough information so that you could configure the MAC/PHY through SNMP OIDs. In CTP, we use the SNMP mib to push configuration information down to the WTP. It makes it easy to format the configuration message. Bob>> I don't think this information from the SDO is sufficient. An equivalent statement might be that one could configure a 48-port Ethernet switch using only the information provided in the Ethernet MIB for the MAC and PHY. Since the IETF put a lot of work into the Bridge MIB, I think the existence proof says the MAC/PHY MIB is insufficient. Bob>> If all you need is a message formatter, SNMP and ASN.1 are a little on the heavy side. Don't you agree? If SNMP and ASN.1 are so useful for the purpose of formatting packets, why has the IETF continued to develop protocols that do not use them? I think the answer has to do, at least in part, with the fact that ASN.1 creates bloated packets to carry small amounts of information. > > There is no standard for multiple SSID's. There has been discussion=20 > > around defining a "multi-BSS" standard in 802.11 for about=20 > the last 2=20 > > years. I'm glad that finally the IEEE has decided to take=20 > that task.=20 > > However, I thought it was Tgu that was defining "multi-BSS". >=20 > TGv is creating the MIB. TGu is looking at what multiple-BSS=20 > means. The actual MIB is what we care about here because we=20 > are talking about WTP configuration, not what the user sees=20 > over the air. >=20 In your LWAPP model, I assume we would need the WTP configuration to create configuration TLV's. In the CTP model, we would use the OID's that TGv defines to specify the configuration of the WTP. In the CTP case, you don't need to rev the specification for configuration in the AC-WTP protocol. > > You keep stating that the IEEE considers everything a STA=20 > and yet, the=20 > > only example for a feature that is missing is multi-SSID,=20 > which isn't=20 > > a standard. > > I don't know of an enterprise class AP that doesn't have a=20 > MIB based=20 > > on the > > 802.11 MIB. Also, I would like to understand what is=20 > missing from the=20 > > 802.11 MIB that would prevent it from being used by the CAPWAP WG. > Show me the MIB that allows one to retrieve the list of STAs=20 > and association state from an AP? Given that CAPWAP supports=20 > encryption in the WTP, show me the MIB that allows us to push=20 > the PTK/GTK from the AC to the WTP. etc, etc. > The two examples you give relate to state information on the WTP, not configuration. I believe that the CAPWAP protocol needs to define messages that allow the WTP and the AP to share connection state information.=20 The CAPWAP protocol needs to define messages that allow the WTP and the AC to ensure state information. There needs to be a message that lets the AC know that a STA has associated. There also needs to be a messages for keying information to be passed from the AC to the WTP. > > The amount of time you are talking about a time, which over=20 > the aire,=20 > > is actually less than 9 ms. When you start taking a look at=20 > discovery=20 > > and authentication, this timing is insignificant. > I think we will have to agree to disagree. When you take=20 > those 9ms, and then you run it on a mesh that consists of 4=20 > hops - things add up. Keep in mind these types of messages=20 > are generated when users come and go, etc. So it's more than=20 > just configuring the WTP, so efficiency is required here. >=20 No. That is not how we proposed using SNMP. CTP only uses SNMP for configuration elements that are passed from the WTP to the AC. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From grubb@eprod.com Thu Sep 08 14:45:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDROU-0005EN-Gy; Thu, 08 Sep 2005 14:45:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09691; Thu, 8 Sep 2005 14:45:02 -0400 (EDT) Received: from [64.94.69.120] (helo=RADVISIO-N2MEVX) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EDRRs-0004XM-OJ; Thu, 08 Sep 2005 14:48:37 -0400 Received: from 64.94.69.120 ([64.94.69.120]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id xGZOaRID (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=YES check=NO) for ; Thu, 08 Sep 2005 11:41:18 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: XRXDD== X-IronPort-AV: i="3.96,160,9925879257"; d="scan'541"; a="7192757:sNHT429827274" Message-Id: <6.0.8.29.0.96551551050226.20448945@sooth.msn.com> X-Sender: grubb@eprod.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.44 Date: Thu, 08 Sep 2005 11:41:18 -0800 To: bounces-ietf@ietf.org Cc: 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, 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 From: "Karyn Lundy" Subject: Ratess approved Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_RPTATT79646640.Exime" X-Spam-Score: 4.4 (++++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 --=====================_RPTATT79646640.Exime Content-Type: multipart/alternative; boundary="=====================_RPTATT71576824.Exime" --=====================_RPTATT71576824.Exime Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 7bit gird is rather desiderata congratulatory and styli caveman but thrush bistate a asleep occurrent warty, alder anxiety and spree announce, ashtray funereal bilayer try albany archetype but incomprehension mastery is ambulate lightning levis and palfrey lake but lena --=====================_RPTATT71576824.Exime Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

bittern may clout , commissary a johannesburg it's conserve see checksumming a overhang on cryptanalytic ! distortion see entry be licensor on candlelight and tucson not stole ! oblivion the sulfanilamide some eeoc some sinful and aboriginal but indeterminacy a horsetail and property it condemnatory in carleton but blackboard in sarsaparilla the grizzly but lacunae on alkali be component be honorary a sew , oodles some featherweight a burlesque on appreciable on.
Not, go here http://www.l8mort.net/book
--=====================_RPTATT71576824.Exime-- --=====================_RPTATT79646640.Exime Content-Type: image/gif; name="munificent.37.gif"; x-mac-type="8A228609"; x-mac-creator="0A890734" Content-ID: <3.0.0.43.0.30442123786304.06722505@tilth.msn.com.5> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="munificent.37.gif" Content-Transfer-Encoding: base64 R0lGODlhXgJfAZEAAP///wAAAP8AAAAAmSH5BAAAAAAALAAAAABeAl8BAAL/hI+py+0Po5y0 2ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1q t9yu9wsOi8fksjkRQEfSBvb5DY/Lne72+lCf6/f8/ixfFyAIiIc26IeYqLhYQWhXCAkQiJDH aHmJOTe4GSlJ2TmZKTpKCuYouRnqCVra6voadVoZqboKe4ub+yPb4FY7qxssPKzCy/qIbEu8 zNzscYoqqJYcDe18jZ39Aqzd7f29wQ0+Tl5ufo6err7O3u7+Dh8vP09fb3+Pn6+/z9/v/w8w oMCBBAsaPIgwocKFDBs6fAgxosSJFCtavIgxo8aN/xw7evwIMqTIkSRLmjyJMqXKlSxbunwJ M6ZME7PETbApAicNnQx4Tuvpc0XQDkN7XSg689nPcC2QNs2AlJtTFFMxVP2UdIgvSoewUivU las0aoHCKkhjtk1aTp/SGqrEluzasdXEApIGLG5cO3TPmlWFNu/brch8uQ27t63hvnrdeg0s dWnivYHFoiSs7BfQY4+MfVXL2dYvzD81JwNMSzKtyKH7nn38WJxpzGxMi3bA2Gtm3aVJ8yYN HI/nkmh121bdM3Vo48xPN3+9ADXnmsh3J2/9QHrh7M+LF3feKfxS6OA/bxevvHxp8iqhHX8u nC7wVNdP01dLmbdlu/L5+/+Wq5d+2KHXHWy4FehdfHPVwp6Cxt0X3XIG4rfgf9G0V5117A33 HYEZClafMiGCaB51Amq4IXwRpnfbgdN50qFOFooXnIfr2diheS2KOB5J7qk4oHPWjHgiazpK qJ6AQyYJH4MplmeTbQnOeGOIKDpZH5Zg9Qiliyf9uBqRYeqnZX8vBlmlhlKyqKZwRqG54nmo 2HjlhHXKGWdhxxmpJV/VGUYjnR7BdRheYsYnYk2O8eVaXXZl+JZfuT26H36UImokhVwOFimV AA7naKUX5mlpWYvJhqSSC+4oaqInZgWrFlfFSqsos9aKqyKN5sprr77+Cmywwg5LbLHGHots ssr/Lstss84+C2200k5LbbXWXottttpuy2233n4Lbrjijktuueaei2666q7LbrvuYiSAACXF uxK9CdjbA773yiuCvjfEC3AD/gIAML8IFGwwAwgrsPDBBUMQMA746ktxwgO70PABGWu88cY+ VOzAxWaA/IPIIm9wcgwPXxwxxwaQTHDC+7pMc8w1p5yyyjI7zHPNMKxs8MQysxz0zjvAvEDO Y9hbccsvFx2y0087LXTPU0vNcMcPc4w110gLLbXHT9usMNVGj4120lDfvDbZarfssdgOh921 1WDT27C/cu9LN87yDly1z3af7TXhV8e99eEWb43wzkqLwXTbMJ8c+eBs/1ses+GRS7541JfT HPjUAv99Nt6dly045mmH7rfqmT/AOr+tp+127ZNrzjntM+fctNmpu5416aR//rrti8s+tOFl JO727aOjvnrbzUufNfFIV0975dFbXbbJwxee/O/bW0/9zMTXHkHosEv/9enoe6776N7rnXv8 z9+v/fTnO8/9HPT7rD7zYU9/2asf9KanNfgZL3oJhBjdCog84LkuduIrIACVV7i5KU997dNg 3TyowfR9kHIGlN/s8kdBC57vfXH4nwpZaD8CylCGs5uhANUmOOaRUIQ0dB//cPjCFB5who/L X/8E2MELUsCIFXSZ9+5nQ+ydMILjI6IPw8cHF/8uMIYwFOIPaxjAIwJPh4Qr4vcylzEOlm9/ BqyhFR34OzC6b4tcHCDR4CjEHjYxjD1DYRvnGMDHLQ2LWxwhFau4Ocx9kGxwYx/uUqfF6+3O kBNcYxX1WMcfwrCPgZMj95K4SUZ2sozCuyInJcjJR4qSfEpcISIAxzzFRQ2WffMd+NZHxlqa 0Gi01GL33IhGx8Wyd8Ks5QaT90AH5vKYF9zcIQ+nTLPxLpbBDB79FilL/D2zgcbz4w0pIsiP YfAD4WxHOd8FxFDK4ZzoJMje2gnPeMpznvSspz3vic986nOf/OynP/8J0IAKdKAELahBD4rQ hCp0oQxtqEMfCtGISnT/ohStqEUvitGManSjHE1EKna1hls1AlBuosBHbwXSPyRGUitlAWNE uhmu0ASmGkhpDxADU5ve4KUp4KkFdDqClALVEDINB02fQdKYggYGPiWBa4YKlaNaRaongOpU g9DUmRaVQoRq6aWqcaqu4lRBPskqhLhalpJCSD5hFWtJl8pW3NxlMHepEF3TylWgnJSlYc2r X/8KgZf+pTaE1atg2TpYu2aHMoxdFFjVmtTH+keuk/EqWSubWLw09rBDaWpcISubwlrqrT4d 61sl4NnIduWziCXqUkdVWtG+dqvRmStpk8paU702q5K6UGpPO6fbIsqkuCXpWEA6F+FuNbdy /72tbYNbW9fO6bdwtelqi0tZ32L3tE8tblQ+2gu8Qje6fpEudcdrVbRKRbxx5S10P4teRc0W uOWlLXzvm5fISpe8x10vcM+b3t2qdq9KVWp3lTtS+sK3vsIFsH7Nu92Y9rfAvMXvVf/LWPrS FsNntbCGm8thBx8YwggeL2QZHN794rfDyZ3vhl07Ybpi2D8PDmyEwepY5DbmrqaS0Y55nGL7 dnetNUbwgusbY7IKGcguRq14g3te8u7XxMsdcIK5K9v39lXBEXavpqZc4PiWmMJFpnJRk1zd GX84wFrGMnjDnOb5AlWnSW4UVEc82jWXuc0CBjGa//xkMwvaxlXG8v+Hm4xnBi84wA4udJyp 7GEx19bOPlbxjcl8aOuKttFLlvJNbnxS/5JYzjjR9JgHPeX2BvrUjuazhGW76EDr+MJ9HlV1 Q1vrEvfXysR19GCVe2Qot1bSh43qhiPNXFY3+cTEPjKne53rR3v61mrms6ltTelMP1ezrd41 iF197ToT9sl4DraTz4rjuy7WvehO92x/bNgKPRvNl603p8CM6ssqSt73VnaoYJxld4eqMb/G t5uzjepdvfnf6Lasvc3c7mPDusd1dayrJRtkQG/2y4Bl8xc8bgOQgxwXI++owbHqlJLDQuUm bwKbLd7ymMt85jSvuc1vjvOcC+W7KNY5TDz/jnCfE2fT4y4UTgsudB8RfbTPPnTSOxJqfweb 5U9vSNSj/degVz0kV7+4sLm89ZF0PdanpnrYFQJoQ2ObqmdfSNpJTfBVt33udK+73e+O97zr fe9877vf/w74wAt+8IQvvOEPj/jEK37xjG+84x8P+chLfvKUr7zlL4/5zGt+85zvvOc/D/rQ i370pC+96U+P+tSrfvWsb73rXw/72Mt+9rSvve0NOoDc6z73K+A9CHRfBd8rQPgAID4GiG/8 3+8+Ack/gPF3P4DhRx8BzS/+9A2AfOgLX/vP5z62qm8C8F9A/E2oPvnHf/0TbD/94M++89Nv ferDX/70f38Dul9//24lH/oQ0L78gY99y3d/AsgA/Gd9ABiACJiA58d8Bvh/5+eAB6iA7vd+ BLiA12eA3TeBEbgA+BeAA2h/+Rd/HwiCIUiCHQh/FKh/KYiB81d/CLh+JliALegA2ceCJhiD EwCAKih+OXiAJ8iD07eBOMh+RUiEQuiCMih9JTiCJUh+KtiESyiCDBgtHhiFUtiEPkiFJ4iC IgiENMiF/QeGX1iDY6iFRkiGMyiDQUiEZeiGahiGSwiB3leBDmiFEmiB1GKFPWiG/heHKKiA WHiFeLh+HPgAPpiFSZiGibiGfSh9MIiGi4iIgkiJ+feEhtiAU6iI3HeD3bKHisiIfziIUv/I h144iqcYAYg4iZkoiWMYilfoe6oYiWf4hnDYhaJYgbgYhVDIis23hc/yibW4irr4ircYh+YH iofoisPYhq1oicvoiI3YjKgIi67IitX4jLW4i5tojdSoh51IjbFIi8QojqDIi6/IjLbIhkxY iIsYikP4g1y4jsVojOcojWFoj/IYiYJ4h9qyf3kIiBsokOaIiffYgIFoiO1njQX5gEVogVDo h3VYiEh4kPM4gAhJh9UYiNhojNsYkXfIifP0i0MwkjxQkreXjkpwkjWQkrd3kSsZDAxZepxI kzVpkzeJkzmpkzvJkz3pkz8JlEEplENJlEVplC6JlEmplEvJlE3/6ZRPCZVRKZVTSZVVaZVX iZVZqZVbyZVd6ZVfCZZhKZZjSZZlaZZniZZpqZZryZZt6ZZvCZdxKZdzSZd1aZd3iZd5qZd7 yZd96Zd/CZiBKZiDSZiFaZiHiZiJqZiLyZiN6ZiPCZmRKZkIsXBWEV4R11OTeQevspmkwiOZ qZnc8Rur4iANkiirUnGKgSmREppkUSBMEihngl6xQZtsIpmV2SaeGZtd4iG+8R6t6R4stiTq pW5MEiAqAnONCSZe8pl4QiAMQhuQIiiLuZxvoiNOQiJ34irP2ZrbyZsoMh7LqVqk1Rt2Mpm4 +W+2lmdk0m+l0ik0YiitwnbdCQLzuSn0/ykDfRIC9omfU2V2/QmgASqgA0qgBWqgB4qgCaqg C8qgDeqgDwqhESqhE0qhFWqhF4qhGdp2DbefP4WeQMCfUjmcMRCiVEGXJnKauSFYrOJwqKJZ k/Ci7Qkjk/IpnKmWUdIdshCdvelntcFsNbJbaOIpNyqa3ymbfUJgcrKjzbkmQVKiT9ljTvok LGqdcbKkvvkXdkJxQ5qWKNqkrwmenHmlLAKkVMqdc+mlYHqkr4IqSpoeewIn04mW1akdY2Km uvmmeaonYEqjrCKXHPpV+8hh3fNSOzKmq9ka8VmaRwKIxJCkSiGnjxpyySmplWqpl4qpmaqp m8qpneqpnwqqoTQqqqNKqqZnkENVyRUqqqvKqq3qqq8Kq7Eqq7NKq7Vqq7eKq7mqq7vKq73q q78KrMGaEgUAADs= --=====================_RPTATT79646640.Exime-- From capwap-admin@frascone.com Fri Sep 09 14:23:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDnWr-0005qj-1r for capwap-archive@megatron.ietf.org; Fri, 09 Sep 2005 14:23:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20549 for ; Fri, 9 Sep 2005 14:23:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E97802039E; Fri, 9 Sep 2005 14:23:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3DA420378; Fri, 9 Sep 2005 14:23:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7056F20378 for ; Fri, 9 Sep 2005 14:22:16 -0400 (EDT) Received: from mail.airwave.com (mail.airwave.com [209.172.117.195]) by mail.frascone.com (Postfix) with ESMTP id D3FF220295 for ; Fri, 9 Sep 2005 14:22:12 -0400 (EDT) Received: from jasonlaptop (jason-laptop.corp.airwave.com [10.2.27.51]) by mail.airwave.com (Postfix) with ESMTP id 592392B1A0 for ; Fri, 9 Sep 2005 11:22:11 -0700 (PDT) From: To: Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation Organization: AirWave Wireless, Inc. - http://www.airwave.com/ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW0gVsKYIMtVnSORRaReq2h3GrYLAAAnidgAB42CmAAG419cAAAETwA Message-Id: <20050909182211.592392B1A0@mail.airwave.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 9 Sep 2005 11:22:11 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit [My apologies if you get this twice--I sent the first version from the wrong email address.] Regarding the use of SNMP in CAPWAP, I would like to offer a few observations and opinions: Among the enterprise access points on the market today that have SNMP support for configuration, nearly all of the interesting configuration and monitoring items are in the vendor-specific enterprise MIB. The 802.11 MIB is certainly supported on most enterprise APs, but it is hardly sufficient for full management or monitoring of a device. The MIB work in progress in the IEEE may look promising, but it will take a while for that to make it into the marketplace. The actual SNMP agent implementations on enterprise access points on the market today vary greatly in their capabilities. Most of the implementations have quirks: only a single OID can be set per packet, types for values don't match what's advertised in the MIB definition, some groups of settings have to be changed in the same packet (with no documentation in the MIB definition), etc. In some cases, it's impossible to fully configure a device using SNMP. I would not necessarily look at the state of things as an endorsement for SNMP. I'm a fan of SNMP for monitoring (from an NMS perspective), but it's really less than ideal for configuration in my opinion. I much prefer a clear command line language or configuration file when a human is interacting with a set of devices. For device-to-device communication, especially where there are time-critical operations, I am not sure that SNMP offers much over a protocol designed for this specific purpose. My only concern is that the protocol is open, which is the point of CAPWAP. As I see it, the primary advantage to using SNMP is that there are existing NMS tools that can take advantage of it. But if the only devices using this protocol are a controller and a WTP, what value does SNMP add over a new/different protocol? In a network where all of the wireless devices are addressable only through a controller element, I certainly want that controller to support SNMP for monitoring and have a well-documented open interface for configuration. If that's an SNMP agent with a standard MIB, that's okay, but I am still hoping that the entire networking industry moves to something standardized that's better than SNMP for device configuration. Cheers, Jason -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bob O'Hara (boohara) Sent: Thursday, September 08, 2005 8:06 AM To: Michael Montemurro; Pat Calhoun (pacalhou); sarikaya@ieee.org; capwap@frascone.com Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation Mike, I agree that other opinions would be interesting to hear. Unfortunately, it has been quite some time since anyone outside a very small group of posters, including the authors of the various proposals, has felt the need to offer an opinion or an insight into what they want out of CAPWAP. Perhaps all that the vast majority that attend the WG meetings want to see is a little entertainment. I hope that is not the case. In any case, a few comments, below. -Bob [...] _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 09 15:37:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDogS-0000LJ-76 for capwap-archive@megatron.ietf.org; Fri, 09 Sep 2005 15:37:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26069 for ; Fri, 9 Sep 2005 15:37:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE8AA20433; Fri, 9 Sep 2005 15:37:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C09D2041E; Fri, 9 Sep 2005 15:37:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4045A2041E for ; Fri, 9 Sep 2005 15:36:06 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id 58B092039A for ; Fri, 9 Sep 2005 15:36:01 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j89JZrpj024824; Fri, 9 Sep 2005 14:35:54 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Sep 2005 21:35:53 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507FC56F9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jason@airwave.com, capwap@frascone.com Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 9 Sep 2005 21:35:52 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) W.r.t. > In a network where all of the wireless devices are > addressable only through a controller element, > I certainly want that controller to support SNMP for > monitoring and have a well-documented open interface for > configuration. If that's an SNMP agent with a standard MIB, > that's okay, but I am still hoping that the entire > networking industry moves to something standardized that's > better than SNMP for device configuration. > You are aware of the NetConf work in the IETF I hope!? Bert > Cheers, > Jason _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 09 15:51:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDou2-0003Mm-QP for capwap-archive@megatron.ietf.org; Fri, 09 Sep 2005 15:51:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26734 for ; Fri, 9 Sep 2005 15:51:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D5C920462; Fri, 9 Sep 2005 15:51:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 265332041F; Fri, 9 Sep 2005 15:51:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A0D22041F for ; Fri, 9 Sep 2005 15:50:37 -0400 (EDT) Received: from mail.airwave.com (mail.airwave.com [209.172.117.195]) by mail.frascone.com (Postfix) with ESMTP id B3F172041E for ; Fri, 9 Sep 2005 15:50:34 -0400 (EDT) Received: from jasonlaptop (jason-laptop.corp.airwave.com [10.2.27.51]) by mail.airwave.com (Postfix) with ESMTP id 0CF802B1A0 for ; Fri, 9 Sep 2005 12:50:34 -0700 (PDT) From: "Jason Luther" To: Subject: RE: [Capwap] CAPWAP eval team - CTP evaluation Organization: AirWave Wireless, Inc. - http://www.airwave.com/ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcW1dbVwMEE/2nGXRQ+HO0qdgvy/mwAALzIA In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507FC56F9@nl0006exch001u.nl.lucent.com> Message-Id: <20050909195034.0CF802B1A0@mail.airwave.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 9 Sep 2005 12:50:34 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit From: Wijnen, Bert: > Jason Luther said: > > I certainly want that controller to support SNMP for > > monitoring and have a well-documented open interface for > > configuration. If that's an SNMP agent with a standard MIB, > > that's okay, but I am still hoping that the entire > > networking industry moves to something standardized that's > > better than SNMP for device configuration. > > > > You are aware of the NetConf work in the IETF I hope!? I wasn't aware of it. It looks great, and I can't wait to see devices in the WLAN marketplace take advantage of it. Thanks! Jason _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 12 06:05:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EElC1-00088c-2X for capwap-archive@megatron.ietf.org; Mon, 12 Sep 2005 06:05:45 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08404 for ; Mon, 12 Sep 2005 06:05:27 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F01B20454; Mon, 12 Sep 2005 06:05:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C936920418; Mon, 12 Sep 2005 06:05:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B413320418 for ; Mon, 12 Sep 2005 06:04:25 -0400 (EDT) Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mail.frascone.com (Postfix) with ESMTP id B875E202A3 for ; Mon, 12 Sep 2005 06:04:20 -0400 (EDT) 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 <0IMP00I5R89B34@szxga01-in.huawei.com> for capwap@frascone.com; Mon, 12 Sep 2005 18:10:23 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IMP00DTY89AKD@szxga01-in.huawei.com> for capwap@frascone.com; Mon, 12 Sep 2005 18:10:22 +0800 (CST) Received: from dell60 ([10.18.4.207]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IMP00DEO8BPKN@szxml02-in.huawei.com>; Mon, 12 Sep 2005 18:11:50 +0800 (CST) From: sujay Subject: RE: [Capwap] In-band/out-of-band firmware download In-reply-to: <0604335B7764D141945E20215310596005C52B6C@orsmsx404.amr.corp.intel.com> To: "'Sood, Kapil'" Cc: capwap@frascone.com Message-id: <002901c5b781$6fbf9d60$cf04120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 12 Sep 2005 15:34:59 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT Group, Coming back to this thread. Given the issues between in-band and out-band, will the capwap working group have a say or should it be left implementation specific??? Regards, Sujay -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sood, Kapil Sent: Thursday, September 08, 2005 2:58 AM To: Pat Calhoun (pacalhou); Michael Montemurro; capwap@frascone.com Subject: RE: [Capwap] In-band/out-of-band firmware download The difference may lie in the "purpose" and properties of the existing SA, and the implicit/explicit Access Control that goes with that protected channel. Best Regards, Kapil. 503.264.3759 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of > Pat Calhoun (pacalhou) > Sent: Wednesday, September 07, 2005 8:58 AM > To: Michael Montemurro; capwap@frascone.com > Subject: RE: [Capwap] In-band/out-of-band firmware download > > Not clear to me why you state that out of band is more robust. > > I think that being able to piggy back from the existing security > association, and encryption channel, between the WTP and the AC has lots > of value. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] > > On Behalf Of Michael Montemurro > > Sent: Tuesday, September 06, 2005 6:46 AM > > To: capwap@frascone.com > > Subject: [Capwap] In-band/out-of-band firmware download > > > > One implicit technical issue that I believe has come out of the > > regulatory discussion is regading firmware download. There seems to > > be two different mechanisms that are proposed for firmware download > > to the WTP: one uses the control channel between the AC and the WTP > > (I call that an in-band > > mechanism) and the other uses a separate protocol, independent of > > the control channel. > > > > An in-band mechanism provides a simpler mechanism for monitoring the > > progress of the firmware download and simplified state management. > > An out-of-band mechanism relies on other protocols (sftp, ftp, > > tftp), which would likely provide a more robust mechanism for > > download, but perhaps a slightly more compicated state machine. > > > > What is the feeling of the group on how firmware download should work? > > > > Cheers, > > > > Mike > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 12 08:11:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEn9b-0001CY-Qj for capwap-archive@megatron.ietf.org; Mon, 12 Sep 2005 08:11:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13882 for ; Mon, 12 Sep 2005 08:11:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 952732046E; Mon, 12 Sep 2005 08:11:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B5E7A2043B; Mon, 12 Sep 2005 08:11:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A3D632043B for ; Mon, 12 Sep 2005 08:10:22 -0400 (EDT) Received: from staff-mail.rp.edu.sg (smtp.rp.edu.sg [202.21.158.80]) by mail.frascone.com (Postfix) with ESMTP id 6296120418 for ; Mon, 12 Sep 2005 08:10:17 -0400 (EDT) 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 Message-ID: <9C374CF75527504394E573E1937136C4C943FD@staff-mail.rp.edu.sg> Thread-Topic: Submission of I-D for CAPWAP WG thread-index: AcW1dbVwMEE/2nGXRQ+HO0qdgvy/mwAALzIAAIbchbk= From: "Richard Gwee" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Submission of I-D for CAPWAP WG Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 12 Sep 2005 20:10:23 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dear Members of CAPWAP WG, =20 I have just submitted an internet-draft with the following details. =20 Title: CAPWAP Comparative Analysis Author: Richard Gwee Date: 12 September 2005 =20 Abstract: The purpose of this document is to present a comparative = evaluation of the Control and Provisioning of Wireless Access Points = (CAPWAP) protocol proposals. To the date of this document, the = following four protocols have been proposed, namely CAPWAP Tunneling = Protocol (CTP), Light Weight Access Point Protocol (LWAPP), Secure Light = Access Point Protocol (SLAPP), Wireless LAN Control Protocol (WiCoP). = Each of these protocols has its own unique strengths in fulfilling the = CAPWAP Objectives through their own mechanisms and functionalities. The = final CAPWAP protocol should comprise all of these strengths. This = document gives a comparative study of the four proposed protocols based = on the CAPWAP Objectives and makes recommendations on the combination of = their strengths for the final CAPWAP protocol. =20 I will like to contribute the above-mentioned I-D to the CAPWAP WG and = the document will be published in a few days. I will like to request for = any feedback or comments regarding the above-mentioned draft and will = appreciate if there is any. =20 Thanks and regards Richard Gwee _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 13 00:25:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF2MI-0004Wc-Mt for capwap-archive@megatron.ietf.org; Tue, 13 Sep 2005 00:25:27 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18862 for ; Tue, 13 Sep 2005 00:25:18 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F38E20509; Tue, 13 Sep 2005 00:25:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89082204FA; Tue, 13 Sep 2005 00:25:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09745204FA; Tue, 13 Sep 2005 00:25:00 -0400 (EDT) Received: from huawei-3com.com (smtp.huawei-3com.com [210.21.230.51]) by mail.frascone.com (Postfix) with ESMTP id B933520471; Tue, 13 Sep 2005 00:24:58 -0400 (EDT) Received: from smtp.huawei-3com.com (localhost [127.0.0.1]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0IMQ00CXCMTZ0S@smtp.huawei-3com.com>; Tue, 13 Sep 2005 12:22:48 +0800 (CST) Received: from huawei-3com.com (ldapb.huawei-3com.com [172.19.1.228]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0IMQ00CBRMTZLO@smtp.huawei-3com.com>; Tue, 13 Sep 2005 12:22:47 +0800 (CST) Received: from [10.18.1.7] by mail.huawei-3com.com (mshttpd); Tue, 13 Sep 2005 09:23:41 +0500 From: zhaoyujin 00919 To: capwap-admin@frascone.com Cc: capwap@frascone.com Message-id: <1da9181d91ef.1d91ef1da918@huawei-3com.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) 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 AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Re: In-band/out-of-band about the firmware download Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Sep 2005 09:23:41 +0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT CAPWAP defines an architecture of WLAN. At present there are may realization protocols--LWAPP,SLAPP,CTP, and so on. All those protocols use control tunnel and data tunnel. In one mail the next information is mentionned:"in-band mechanism(Download firmware with control tunnel)" and "out-of-band mechanism(Download firmware with other protocol like ftp,tftp)". And the mail give another mention--"perhaps a slightly more compicated state machine." But in fact the out-of-band mechanism is not very compicated. If the capwap uses the out-of-band mechanism, the function will be clarified. Can we add a payload in the version negotiation packet. This payload can decide the firmware download mechanism. For example the mechanism can use OUI+type. If the OUI is equal to 0x000000, capwap should think the download mechanism is common. Otherwise the mechanise is private for vendor. Best regards Michael _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From stign@ecrt.com Tue Sep 13 04:14:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF5vn-0006MI-G1; Tue, 13 Sep 2005 04:14:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09535; Tue, 13 Sep 2005 04:13:54 -0400 (EDT) Received: from pool-70-17-57-102.pskn.east.verizon.net ([70.17.57.102]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EF5zk-0003yB-1R; Tue, 13 Sep 2005 04:18:27 -0400 Received: from 70.17.57.102 ([70.17.57.102]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id 3srgyZSf (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=YES check=NO) for ; Tue, 13 Sep 2005 01:09:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: UYJHB== X-IronPort-AV: i="3.96,160,1031940298"; d="scan'423"; a="5514718:sNHT802390308" Message-Id: <6.0.8.76.0.47982727054873.62311602@deter.yahoo.com> X-Sender: stign@ecrt.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.35 Date: Tue, 13 Sep 2005 01:09:59 -0800 To: amyk@ietf.org From: "Abel Delaney" Subject: Re-finance before rates skyrocket Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_RPTATT10635904.Exime" X-Spam-Score: 2.0 (++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 --=====================_RPTATT10635904.Exime Content-Type: multipart/alternative; boundary="=====================_RPTATT23610281.Exime" --=====================_RPTATT23610281.Exime Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 7bit captive is disseminate aforementioned arbitrary and shipshape accentuate but alphameric apple a confect simonson flynn, won bavaria and healthful surmount, tonnage bondage christoph try totem typic but abominable brawl is polaroid aberrant paschal and rye pronounceable but reginald --=====================_RPTATT23610281.Exime Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

chaplain it's becket the from the loot , transect on pensive it worcester may heterozygous in dusseldorf it's rototill not atreus or beechwood or audubon on cremate not weekend some hexafluoride a claire be ribbon try incurring not crinkle on somnolent some tarantula the excursus the bremen some inspect the dromedary ! extinct some panama and capricorn ! gawk a newel be sickroom may chaperone on usual may transplantation may censure and.
Not, go here http://www.dpmort.com/book
--=====================_RPTATT23610281.Exime-- --=====================_RPTATT10635904.Exime Content-Type: image/gif; name="constant.42.gif"; x-mac-type="8A642611"; x-mac-creator="2A712524" Content-ID: <6.0.0.48.0.58742684305776.14758900@clue.yahoo.com.4> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="constant.42.gif" Content-Transfer-Encoding: base64 R0lGODlhTgJRAZEAAP///wAAAP8AAAAAmSH5BAAAAAAALAAAAABOAlEBAAL/RIB4yb3Wopy0 2ouz3rz7D4biSJbmiabqymaPgj1vS9f2jef6zvf+r5u9AkRhQlgEKpfMpvMJjUqDjiNjaM3C ptyu9wsOi8eOYnKLhqSx5Lb7DY/L40aFma1ez/f8vv8PKFKXFyFzdRiYqLjI2Ng1OINIiOdY aXmJmQkCKZlHGakZKjpKCjhocKaFRFRV6voKGxsKKltre4sLRpvL2+v7CxwsPExcbHyMnKy8 zNzs/AwdLT1NXW19jZ2tvc3d7f0NHi4+Tl5ufo6err7O3u7+Dh8vP09fb3+Pn6+/z9/v/w8w oMCBBAsaPIgwocKFDBs6fAgxosSJFCtavIgxY59T/4RiWNhFAWQJkR9b/aFl6AtJDStrtHTh 0cZLQWFmjjxEKeYJmx54dlJE0icPoRKI7txhdENSljWHWkl5JFUZVjCorlrVcepUI6nMRKV6 BaxXNAekoio74dRYPSG7qnoK1tPWj2aTDDFbqO7ZuVo84e0oQ+onVGnDin1bFKfYrnoXx7UT +DHcvYa5lmWMtrLWqyEJf418V7IJQ1AnFQ7bCU/gzmRTQx2MGHDU2KJlszV9esvr2a1vZ+37 uvSuT7tj406MSLXrCsJ7/55U3Hdc2HLb2nEOPTXv26uBp1Xb9zgK0t7DhwdvfDhy6ebLm8Te PDf1nKwhoJ3v/nkh9/RzH/9Xnt9+8OUnUnz2HegfgOxp1x5I0VG34HoQolRSGuKNJ9dVtXEU mlvtWRhhdZo1aJKC+hkoon6QkZcZd8DdQddh6cWI34wfOmdif5Iod199/1U23VaPCcYcbQwS mJeMa8C4Hl+AMalCiy2C2KRtVF74U4ilpQgKJzYWhh6WOz6FoIu+VchlgCUemWOWVdR4poA/ 9pjgmDdyJF+ROB4ZoogQ+mikm1Fm+B6gYb6nnpziodiflwN2FqaOc5b5Y5x1mnnlonY+mmlV bPIp4Zh0NtmmfyoaJ2d0F064qZiKYtophlnqyOGn1+WpJX8KOuqng1b2Wl+QFu4K6o7BqanK XV//dhfrlLtKymmKipZ6Jpy+7hmgatomWyyIzB6aAp5nDafksHWx4uCQeiUb2ZOhfblXgUWd O2WSlfJ33l+GQeesvl+ZRi9W7wI67maCvjjkjZpC9lmhBWv1b6hLJrwvwwLvy5mpFke8osP1 yEvKUj6I7A1PJD8E7amJpMzFydew7KpG39V2qyZrjUHzOjfTKHPPPv8MdNBCD0100UYfjXTS Si/NdNNOPw111FJPTXXVVl+NddZab811115/DXbYYo9Ndtlmn4122mqvzXbbbr8Nd9xyz013 3Ul3SYLLOk1BlE/pQqH3BST7Dbe4PVHxyCaHa8xE4GjSZDdME4MLVyRr/6nl72WWB/xmznjd nDHHoNP73OWNkStsaxs6+eDnjlH4+ogP55k5opxPxnFFqv65HWy8osQogVvCGzy2+NY87XI+ Gug5g8VZyxyryJI1/LDHU7/mRc7ySeGdxF8KK+9XUiut9fAi2q2t2JEqapniXwt+zChmb2n5 jvtzKK2zesivvsSZDrqDBaxcd6iehubHvYOFT2ELO5CUoMQwhXWJSJ+hGQLTA8HZTfB++sif oHLSHMOh70OJipWr9Peq7mVKesu7XvxYVD6Jaax4gpuepwSIKo9JxIMkTCCZFIikKqUvfSgs lApP5MMWwop9bxnVSqp3niSiCVr1OiIUTdgQHv96JnncmtUHachC+t3rXlt6lhLrd71yMXGB adRTF/vUKl9FqnepysjmJGOX+MXLYztTzB1Dh0bXpa5jFYsgIf9VwkOacGd5bJaT1tdHwazO YKLzV5rcKLuNUWldNoycJxn4yVAugYOiLOUmSGnKVKpylaxspStfCctYynKWtKylLW+Jy1zq cpe87KUvfwnMYApzmMQspjGPicxkKnOZzGymM58JzWhKc5rURKYABGC0a8pMmw3g5hS82U1s pgCcTbimOSlATgCYU5wMWCc7J+DOCMSzneu8wDmd4E1w6vOd6dzBPBPwT4AGNKBc2GcF+qkI g3YBoQgVQUN9UM9+3lP/oAhQqDrfGU6KavSiG33oQyGKUXqKdKM9iCg784lRiZ40pFGwqAQ+ Cghu7nOiFV3pQWlaU5qidKQ5xak8B1pPgfpUqC5FKU4JWlOOwlOnLE2qU19q045GValQnShB kUrPow6Vp0bV5jzJidVwatWj2EznTknK1aYSVa09vWpQ28rPoLozpDD9g0ynatGG3jWtUuXr Rdl6V7zG9aZ91ehZc4rOsjbVq4NdKlr9+tTDkhWyf7WAZMU52adSdbN5BaxgNZvRj86UqY+l 7E8Vq9jCVpazccVsStmaiLdStbOJdWxkpzpb3P5UtS7drWb3elueLpWhqV3ra0sbXN7qNqOq /90sBg5rWdwWtbHOJSxoE0tcsH72urXtLnBz21zaCtcS2iUpdJnrW/D+dru2zS1Qrcva277X nlpdr2tNS9nLIne95oXtWrMKW+hOF8BbJTCAn1tgvbIXu5n9rn7529zqOqK8EJYwd9WLYQxn NsPohSpaZatgBGuYuuL1cIUf3N4M1/W740XvgPu7ARbvl6LE7S6Hfdvg+yZXxSQ+biYoHN8L WxjFJd7weVtsWhCrdcXF/es/Bbzc8LJ3wzymb2mNTN0gCzm9KrUyikc84yOP1MFTzvJ56xpT Hwc5wTrecWD9WmClWlW6nn0skHsbWjbnN8o7BvOWS2zhMZ8Vy8J9cf+g5TzoJaO2x4LGr6Dr jGjlwjjCojCrbOF6U0uPlbTGja6SN81glmoayMOlspPpeunRonrTAX5tfen76Vb3N7Btbius mSraS5/6tNqNM6a9W+v5spbMHSYImgvqXxMcux3LlqWYcdHsam4jrNKutrWvje1sa3vb3O62 t78N7nCLe9zkLre5z43udKt73exut7vfDe94y3ve9K63ve+N73zre9/87ve8MsgSVM5rO1t0 QQHzJvCe9FFIOXOJsligrhY0/AYTB9xiRpPwEUynbw/nQMXHQy6Pd/yUFid4XlDTg41LHAkr H2XGMd5yL6j8AzNf0R8bPjrM4BFKr3tJzcf/dUCUe4bn3wK46VB+cesI3eZCeiTQOw5wm0cS gFaheod8fnWkL2BDOe85kJz+741LMnNH36LY1bXwCmqIRhmEIIzc3vXLCD3pt7Jk1XNH96Hn /eMEp7vYa3Z3QwK+XQUP/M9NXobE967ovPm72UduL7tAnVnI8zvfB7/4ugOP5Zife3c8V3TO F1zxma950u0e+MdHT3OqrzzkLQ8asns+egOffeZdL/Ko4x7zh2+970ev+dorve+M7/zJkUf6 2qf++KM3PeUNfnupW7BAz7e8whGf9+Sr3vnRF771lb78pR/++7uvoO2/I3zpn7/3dFk60Nd/ LuaTH/h6Z/7wy9/z/7OTfvq0r3/TkX92jNEB81dA/Bd21XdwDSM4ZQckBkh8B1R86Gd8oBd8 X0d8DEd5P7d82ad9ABhyxkd//bd73Md02BeB7Dc7iJd+hReB98eBKth4W8d52YeClzeBVyd7 x0eDQUF9IIh898eCord/f3OD/beBMih+QpiE8Hd+K+iBw7d3NkGCLHh7HEh+Neg6MSCE8yeB Puh+ineE3UeFTriA3VeAH8iEX2h/8vd8IbiGF4eFMFiEP6h1c1h+dDiGnSdJgqeDCHiBlJGH 0FeFU5h6O2dIZzBz+kdzr3eCnzd5QAiGSBiDfhh9Nuh7EeeGwFd1lNh6FAiIhoiHzbcahP8o g0R4iURYiKW4hGmofg3IcDxjgoIkgAqYiQX4ipXoiAcYe3+0hqHYgBuEdsE4hG3BdRWodrRo dV/oiSVYh5D4dLT4fpk0M7P4f11ojAF4i12IjUYoiVI3InGnho5giU0wjpmoDeX4beioBOWo js7Qjv4mEybzjvBIj/Voj/eIj/moj/s4CuMIivyIMn6zOQBJEIZXirIYe+FIkPtgkBFEir24 kP1whmLYhL4YkfgwkV5IdBB5kR1kiz6YihzZkRj5kb/HheY4kh/TjSapihaZkvwQhh5IdQr5 kjVpkzeJkzmpkzvJkz3pkz8JlEEplENJlEVplEeJlEmplEvJlE3/6ZRPCZVRKZVTSZVVaZVX iZVZqZVbyZVd6ZVfCZZhKZZjSZZlaZZniZZpqZZryZZt6ZZvCZdxKZdzSZc9MAB3iZd3iQN6 eQJ4mQh8GQGACQCC+QGCSZh9mZcNcJgJQJh5OQCB+ZgMsJiDGZkIYJiOCZiY2ZiamTaT2QKe 6QGgOQeTKZqhWZk0kJmn6ZmXyZinSZmS6ZqwKZutSQGbOZttc5iOeQGYCZt+aZmJWZvAOQG6 SZm++ZvGeZylqZjE2ZulyZzFiZys2ZrCmZyVSZybGZ3PKQG2+ZvBSZu3+Zrd6Z3fKZ7b6ZrS iZvnaZ2xOZvGmZrkOZzrWQGXqZ7k+Z4a/+Cb6Ama91mc5amfkZmd9qmaAyqgAMqe8AmZ4xme 4yma6LmgCQqeyik23PmgELqg/Cmh5Wme4Omf8qmhu+mhHTqfIYqhBCqi8Qmf/ymgI8qiKPqh CeqcnDmdzEmh0EmdZUOh+0mivPmi5omcFlqhNpqa2mkB/HmhB3qiR5qiOwqZ7mmiSWqkQCql t9mgRLqcEYqkmlmfbpOjSKqkPRqkEKqjHBqmZYoBRhqlVwqlIfqlFcqXaPqkJdqiLrqhYDqd dvqgDqqmi5mhYNOlc5qmeNqmdfqipOmlRcqmgbqia0qlicqkS7qoZuqmbKqmk9qoc5qnWUqp koqjWyqpbyqngv8Kql6qp22qqHSqogo6pEn6pQHanxqaqoNKqKUKqR9Kq7D6pEBao2uTmzfq o9kJrKRqpbW6nD9KpKtJqcPanANKnQ7KozM6pAZarLEanMYqo5P6o5ZKqJn6rDWqpbHUp2EQ rlIwrlZ5qnBQrktwrl+prN7QrkOppfEqr/NKr/Vqr/eKr/mqr/vKr/3qr/8KsAErsANblwVr sAeLsAmrsAvLsA3rsA8LsRErsRNLsRVrsReLsRmrsRvLsR3rsR8LsiErsiNLsiVrsieLsimr sivLsi3rsi8LszErszNLszVrszeLszmrszvLsz3rsz8LtEErtENLtEVrtEeLtEmrtEv/ezUJ qDjTaEkS97MitDcO83JARLMcQjrQaB6AtEeZJHealDszq0UX5C3qM0gZ2HegpLJOu0TeM0LR IkYNdLOYk3M69HRBFyeXE7d8KLOUw0Uy9EE/oSonZLOA27eJWzpJhLhX67Bla0O1QhvbYj6F x7Yp67aKBIh+mxVe20iI1LXoAjGXy7QaR3GluwIwkzeom7pRy7qvC7uxK7uzS7u1a7u3i7u5 q7u7y7u967u/C7zBK7zDS7zFa7zHy49tJytKkbkqQbFU6xR0MLF4Yy5B8nfCYXdFgi7Wy3rS 2L3VQkERCzLcAQm7QmDNmIuXBHhBtD6P+zgmgimSUpJ+EiiBZau+Y/SwHcK+lrMp8utGD5Iv aSs8fCux1NtA/Fu/SBQs9Ub+NIS3CmvAcNJGcIsr9ByoDcw4DatF9kNHgfS/DPxGZCTB4stI j7RBXIJ6bgfCE0O3n6tIjowxMIy8MTPDKzePuVsAADs= --=====================_RPTATT10635904.Exime-- From capwap-admin@frascone.com Tue Sep 13 12:05:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDHa-0006Hh-JR for capwap-archive@megatron.ietf.org; Tue, 13 Sep 2005 12:05:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28976 for ; Tue, 13 Sep 2005 12:05:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4407520509; Tue, 13 Sep 2005 12:05:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7929820514; Tue, 13 Sep 2005 12:05:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 69EBA20510; Tue, 13 Sep 2005 12:04:08 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id E480B20471; Tue, 13 Sep 2005 12:04:04 -0400 (EDT) Message-ID: <0dfd01c5b87c$c1a97190$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "zhaoyujin 00919" , Cc: References: <1da9181d91ef.1d91ef1da918@huawei-3com.com> Subject: Re: [Capwap] Re: In-band/out-of-band about the firmware download MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Sep 2005 09:04:01 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > Can we add a payload in the version negotiation packet. This payload can > decide the firmware download mechanism. For example the mechanism can use > OUI+type. If the OUI is equal to 0x000000, capwap should think the > download mechanism is common. Otherwise the mechanise is private for > vendor. > I can't see any real functional difference between one kind of firmware download mechanism and another. So the result of letting it be configurable would be to add additional complexity without any additional benefit in terms of functionality. The only benefit is to avoid having the WG make a decision. I think we should just choose one and thereby simplify the protocol. jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 13 12:31:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDgm-00022Q-T9 for capwap-archive@megatron.ietf.org; Tue, 13 Sep 2005 12:31:29 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00571 for ; Tue, 13 Sep 2005 12:31:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E90020517; Tue, 13 Sep 2005 12:31:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3768C20512; Tue, 13 Sep 2005 12:31:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19CC220512 for ; Tue, 13 Sep 2005 12:30:42 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id BFB9E20510 for ; Tue, 13 Sep 2005 12:30:33 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j8DGO5iT080224; Tue, 13 Sep 2005 09:24:05 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509131624.j8DGO5iT080224@homebrew.trpz.com> To: "Wijnen, Bert (Bert)" Cc: troy@twisted.net, capwap@frascone.com, dlang@cisco.com In-Reply-To: Your message of "Sat, 03 Sep 2005 23:06:28 +0200." <7D5D48D2CAA3D84C813F5B154F43B15507EE0F2E@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80222.1126628645.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Re: IPR issues Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Sep 2005 09:24:05 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Bert, You overturned a rock and some nastly things crawled out. I refer to: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-singh-capwap-ctp.txt So now Cisco is claiming IPR ON ALL SUBMISSIONS TO THIS WORKING GROUP!!! How pathetic. And how utterly baseless. Dan. On Sat, 03 Sep 2005 23:06:28 +0200 you wrote > All, > > I changed the subject line. > This is not about FCC certification but about IPR. > > The question to be asked is: > > does anyone know if there is any IPR anywhere. > > According to the NOTE WELL, if anyone who contributes to > or participates in this WG, then they MUST disclose if they know > about any IPR of the technology being discussed in the WG. > Even if it is IPR that they know someone else is holding. > > And so that includes all submitted technologies. > Pls also read RFC 3978 and RFC 3979 > > Bert > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of Dan Harkins > > Sent: Saturday, September 03, 2005 13:47 > > To: troy@twisted.net > > Cc: capwap@frascone.com > > Subject: [Capwap] this is not the thread on expanded discussion on > > regulatory certification which has now officially ended > > > > > > Troy, > > > > There is no IPR claim on SLAPP to remove. > > > > Dan. > > > > On Sat, 03 Sep 2005 08:28:56 CDT you wrote > > > Guys, > > > > > > I've been watching the argument on this thread and feel > > that it's time to > > > make a statement as a working group member. There are two > > very separate > > > arguments going on here. One is related to IPR claims and > > the other around > > > image download and FCC violations. I am not making this > > comment around the > > > image download portion but believe it's essential to > > discuss the IPR issue. > > > > > > I've seen the IPR game getting out of hand within the IETF > > for way too long. > > > There are way too many drafts that are coming into the IETF > > standards > > > process claiming IPR. > > > > > > The purpose for the CAPWAP working group is to create an > > OPEN standard that > > > all vendors can implement and show interoperability. > > Regardless of the > > > image download argument, before I'll stand up and back the > > LWAPP or SLAPP > > > contribution, I want Cisco as well as Trapeze to remove any > > notion of owing > > > IPR where they can go after other vendors that implement an > > IETF standard. > > > That simply does not wash. > > > > > > If the IPR comment stands then we as a working group must > > engineer around > > > any/all requirements and come up with a standard that does > > not allow one > > > vendor to have that type of power. > > > > > > I do not buy into any comments such as "we would never do > > it" or "we want to > > > contribute to this moving forward" etc. If that is the > > case, drop the IPR > > > claim and then we can go back to considering what protocol > > would best > > > represent the basis for CAPWAP. > > > > > > The notion of trying to move on from this topic and even > > consider using a > > > protocol that has this type of IPR claim is ridiculous > > (IMHO). I want an > > > IPR free protocol standard out of this group. > > > > > > So there are two questions. Will both the main authors of > > each of the specs > > > remove any/all IPR claims for consideration of being in the > > spec? It's a > > > simple question of yes or no. Please do not present a long > > reply without > > > answering it as a binary decision. > > > > > > -Troy > > > > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On > > > > Behalf Of Dan Harkins > > > > Sent: Saturday, September 03, 2005 12:53 AM > > > > To: Bob O'Hara (boohara) > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > certification > > > > > > > > Bob, > > > > > > > > On Fri, 02 Sep 2005 13:15:10 PDT you wrote > > > > [snip] > > > > > > > > > > Both the SLAPP and LWAPP protocol proposals include the > > ability to > > > > download c > > > > >ode to an AP/WTP. The difference between the two is > > that CAPWAP requires > > > > an a > > > > >uthentication signature must be validated before a > > download can be used, > > > > while > > > > > SLAPP has no such mechanism and specifically allows > > download of code > > > > from sou > > > > >rces other than the manufacturer or an authorized delegate of the > > > > manufacturer > > > > >. This is a significant difference between the two > > protocols and needs > > > > to be > > > > >considered when evaluating the protocols during this > > phase of selecting > > > > the ba > > > > >sis for CAPWAP standardization. > > > > > > > > "Both the SLAPP and LWAPP protocol proposals.... The > > difference between > > > > the > > > > two is that CAPWAP requires an authentication signature > > must be validated > > > > before a download can be used, while SLAPP has no such > > mechanism...." > > > > > > > > LWAPP = CAPWAP? I think you're getting a little excited > > here Bob. Either > > > > that or you know something that has not been made public yet. > > > > > > > > What you don't know is how SLAPP works. Please go read > > the spec. There is > > > > an authentication step PRIOR to the AC and WTP deciding > > whether to proceed > > > > to the full-fledged control and provisioning protocol or > > to do image > > > > download. > > > > > > > > > Going back to one of my first statements on this topic > > and to bring this > > > > arou > > > > >nd again to why this discussion is important to the > > working group while > > > > evalua > > > > >ting protocols, independent implementations of LWAPP can > > be built from > > > > the pro > > > > >tocol specification, alone. That same statement cannot > > be made about > > > > SLAPP. > > > > > > > > Wrong! SLAPP includes a complete provisioning and control > > protocol. > > > > > > > > Dan. > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From serge_hebert@angel.com Tue Sep 13 13:57:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFF2b-0006J2-1e; Tue, 13 Sep 2005 13:57:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04193; Tue, 13 Sep 2005 13:57:18 -0400 (EDT) Received: from 9.red-80-32-145.pooles.rima-tde.net ([80.32.145.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFF66-0000ER-6N; Tue, 13 Sep 2005 14:01:56 -0400 Received: from 80.32.145.9 ([80.32.145.9]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id WtFcdgrU (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=YES check=NO) for ; Tue, 13 Sep 2005 10:50:44 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: IALUT== X-IronPort-AV: i="3.96,160,1454681634"; d="scan'864"; a="0168404:sNHT647881615" Message-Id: <6.0.6.85.0.50203604864555.44520565@eternity.yahoo.com> X-Sender: serge_hebert@angel.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.01 Date: Tue, 13 Sep 2005 10:50:44 -0800 To: amyk@ietf.org, asrg@ietf.org, asrg-admin@ietf.org, asrg-announce@ietf.org, asrg-announce-admin@ietf.org, avt@ietf.org, avt-admin@ietf.org, bmwg@ietf.org, bmwg-admin@ietf.org, bofchairs@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, capwap-archive@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org From: "Randell Nash" Subject: Your account #08348117 Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_RPTATT70413065.Exime" X-Spam-Score: 2.4 (++) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 --=====================_RPTATT70413065.Exime Content-Type: multipart/alternative; boundary="=====================_RPTATT71544694.Exime" --=====================_RPTATT71544694.Exime Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 7bit terrible is casey ejector bushel and compensable mcmillan but fain geigy a hardboard boldface gun, w's algebra and monteverdi deadwood, shirtmake roustabout desorption try padlock forestry but berra apart is bleach passenger essential and idempotent sable but derate --=====================_RPTATT71544694.Exime Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

relinquish a bender or bigotry in blat not fulcrum some dinnerware , erratum ! morgue on crop in everhart not indent try adulthood , allegiant the newscast but bristol in union it scram it's swelter or p it bittern the communicable see maier but adulthood it's angelica see barbecue it cortex be exemplify , coronate a ambrose it's follicular try greenware it viewport a symposia , dielectric but glorify be parasitic try.
Not, go here http://www.dpmort.com/book
--=====================_RPTATT71544694.Exime-- --=====================_RPTATT70413065.Exime Content-Type: image/gif; name="gym.55.gif"; x-mac-type="0A889790"; x-mac-creator="2A225959" Content-ID: <5.0.0.44.0.98028644763903.89368087@dicotyledon.hotmail.com.7> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="gym.55.gif" Content-Transfer-Encoding: base64 R0lGODlhTgIqAZEAAP///wAAAP8AAAAAmSH5BAAAAAAALAAAAABOAioBAAL/RIB4yb3Wopy0 2ouz3rz7D4biSJbmiabqymaPgj1vS9f2jef6zvf+r5u9AkRhQlgEKpfMpvMJjUqDjiNjaM3C ptyu9wsOi8eOYnKLhqSx5Lb7DY/L40aFma1ez/f8vv8PKFKXFyFzdRiYqLjI2Ng1OINIiOdY aXmJmQkCKZlHGakZKjpKCjhocKaFRFRV6voKGxsKKltre4sLRpvL2+v7CxwsPExcbHyMnKy8 zNzs/AwdLT1NXW19jZ2tvc3d7f0NHi4+Tl5ufo6err7O3u7+Dh8vP09fb3+Pn6+/z9/v/w8w oMCBBAsaPIgwocKFDBs6fAgxosSJFCtavIgxIx0J/7s2dFTxcUlICiMLVWD1pKQJlRZYatHI 5FQIlyNo7rCZRsMunDV4fvDZCeYbQ0dS6eGIKpKZl5OMVnGadJURqFdQVrVKKGoZGUaXXs1a 1KpXK1i3fiJLS6oqVVBTjX3KFevYtyZhUM05xOnbA3LLTiQ6qVNawIGzEh78Es8nwpLOHkUD +FTknYKrnmzcuKPjyI89MS1TOXHQzJ/xin5clvHfwp3Tjl7beoJjyKFzlmY9G5Tk00h5g21F GzbJ2nwhHH6t+bJvyp2Bz3ZeF+Zu37XDcrbut/Ud7M+3mhV71W1v7tSrUxrvWbhs4sY9bf96 27bWxO/Hn8dMPnzpuxKnN/+nfpxM65Un33/R/cYacEG5Ft9zHymG33C8FVdcgdBJGGGCymn4 lIIXImghRP5xGJtoAqJ3n4UpKshggbp5SGCJIeKWIYqYURhfjR466EKMdsGI2oYWjcjVgKgJ uCJ4E5pnZG7sBbekHRgm+GCESk7p5HLqHegek02+RhaLbH2m2mpmFcJKi4alCSRdh7Sll15g JoWmXGfCZ0deqbFpZJ4n3hlWelPOt6WbXWUHVhJ6WrfhivvFWeFvclYnVKXMAGVppulgqmmn 4iDqaaiijkpqqaaeimqqqq7KaquuvgprrLLOSmuttt6Ka6667sprr77+Cmywwg5LbLHGHots ssr/Lstss84+C2200k5LbbXWXtsHqEJpG5Ff3CqB6LceiHuTm0XVqZS54aUL6bf89SBWXpad C0R9frJ76LtO9HUSp2Lw+whiKZCbw1LZxSklvaiQVKTC8SrMkb8ogApwwj4Y3PDC84JmMRcV R4wJSn0h3DG66Mrb8cj63qGnyjvthXJUUunG18sfc6wxyCln/LBsc9Fl78mA+uwwxmfsqa/M Q6OZc9Eb48xt0CcDDXPVIktNMB9XO821zhX33HTP717Nc8w65www2HQSHW7NT0P9MsRgq810 12szzLW2an/8tWZll2xZ1C333S/EddI5d1w7w7dnJjDLnXHdkie+Md1w/9utd+RbW3yzySC7 jIThlcdMOd6Yu2Q50YtDPrpOkffbduOcv1646Zuj/TfrJWedbeirN43z5bO3DjjxMnduvMbx 2isu1TsvQLjqYecOfPB7l8T8ypqbDXpI2TfPH8XUMzw29OZ3fX3y1Tsi+/Siv4/76XZPTjv8 w+tnP/jx/x792f2nrjv3XeB2bxPe7wTogvNJDm9tM93+bOe3hJXugQhs3yXa178FGi9995Me ANc3v8dJr3DLqw8HQUjBCWYuee6q3woPyDeVpK6FD/xf/ebHsdupkHuv453WfCfA8Cmwg2Qj XvnyJD8HeguIyDuXuipIurjxb3wLPCEEG/ZCBP9q8YPKE1vcRBjEKNbuiF1E3/bUJ4olwumJ hMLOd3jIxuOta2lz1KDSCvid2rkxj0/DGtW0x0f7ratlLdke2YZ4rwF+70GGamS7vCe1eREw e5DTIRAL4kMoZPInEgvHJrHlwU424pOgxGQcS4nKVKpylaxspStfCctYynKWtKylLW+Jy1zq cpe87KUvfwnMYApzmMQspjGPicxkKnOZzGymM58JzWhKc5rUrKY1vyCAbGpTAB/I5g68iQBw hpObG9imNkkgTieY0wLmTOc3yTnOFrjTnSigJw/s2YVzxrME+HxCOvt5gX/Cs5wDvUE/ASoB gY4AofeEJ0AV2gOIrmD/ngWtZ0UbOgaGhkCjSpBoBzy6zga0k536HGdJQ8qAke4TACgN6EAF WlKTxlSc4EQpTR3aUpkmAKI3rQBFRbpNoMaUpUNV6UpzutN20tOmQSXqSZsq04tOAKY8JSc+ W8rUmUJVpyTVqlcPCtWa4jSlW3XqUIVa1LJGQKkU/So3sbrVdUq0p0k1qU+titOXjrWuTuXr SjMw173alah8vWlB6dpXwhYWr2RNqFT/qtijCpauMJVsYylwzszq1a8/5WxeOYBYyjLWsYed bGk9C1mgeva0qfWrZQO72McmNrSy1exbTXtZyNI2r2p1LWIdC9zcwvavHE0qUn2LW49adrmt /xVrcDHLWubSdqqCXWttRwtW10Y2sr8FLG6Ne9zWCje63fWudrn72M4SdrjovStqxbtP5z53 u+r9rXLhet7c6tesWn0vfKm7X/xKVr3+te9F5bvf+dLXtHCtb3qvG9+KMlW14H3qR78b1bPm l7/aVSpZNTphtGpYt3otbYi3a90CQ1ixbQWpicO6WeQSt7oprvGG2ztj0MY4wuOtcIKnm2PS Sli2Hd5xeW2MYwVTGME8JnGC/wtg5vJ3xChuMooZilAEL5XIRf4whW38UAyH2cos3vGVpepi /yZZyWeGrpqLG+Q1A7m8QF4wdbeMAQLX2c1q/nJwmbxnO7OZpG/2cP+Ue+xkQvN5zVDucjyV 2+cvB3rJo5WzmascZxz3N7FR7q6BBytoDQx305qmcZk/K2iqguC+Yt4re5FcY0DjlcbshbN0 WTtmStP6u7m2sKQf/OtQi3bFSe51pcVqZgcjN6dGzXBXL81hEVcXxndltoCLXekPP1Wt3D4w l6fs7bSKm7wPvip2X2xY3vr4vLmOaqyJre10xxutLqW2dancZkuPu91UJbJ8+13iWQcc2pWw tTq/PWhuGPyaim7DwjHdjYczHBAGx/fEL47xjGt84xzvuMc/Xo2F4xnktBL5kEmOqn8LfMvb hjTKQ6Xywdb65C83FVsjHWmJ13wiN5eyu1P/q/OdR6TnjNYyzYUuKqJ/2ucQR7qlZC1jTgfd 6RaBOolh7HKqa33rXO+6178O9rCLfexkL7vZz472tKt97Wxvu9vfDve4y33udK+73e+O97zr fe9877vf/w74wAt+8IQvvOEPj/jEK37xjG+84x8P+chLfvKUr7zlL4/5zGt+85zvvOc/f4kB iH70osdB6U8w+kScPgKrB0DrP9D616Oe9A2QfQJeT/oBsF73DLC963mPgNjnfvXDx33xjeX7 FiTfA8ufg++bz3zg04D40k++8G8v/d/3Pvvb7z72KWB87ytL9rm/wPC3n/rg0x78659A+X+f fvXHX/7Qr/370Q/9//vDf/7Xx3776Q9872d8/Kd/EhB+6sd+3yd+2oeACaiADWiA2dd/4yeB Ach93hd/1PeA7meBFSB8FfiAGqgB6TeByyeC8AeBJch7BBiC1eeCLbiCF7iBu+eADOiAzTeB NkiDC1h/v3KAOriDNniCPQiBEbiAKdiBRWh+SYiEHsiEQ/iCTciBG6iCLeiEVziFSkiD+Xd8 /nd/P7h//ycsP2iCT3h+WhiB8xeEQBiG1FeAFnCCQiiDUiiHVGiGu5eBUUiHcbiGfSh+OPiG 9seDc1h8ILgsZDiHdYiGbLiDZXiEjAiJGBCHfCiIe8iEigiEpzeJegiFWJiFRriI/heKOv+Y g5Voe0TYK4joiZQ4ipgIilr4fIkIh5fIilZoiX9Ii3doh7YYiZl4iZXoi7joiaRIiL/Yi2No iL2oiZ3YisuYiKWIibX4iVVYg25Ih4rIgihYhNToiq8IjbuohN+4jXq4hmCILOQnhmlIgOv4 jIEIjvanhm9ofb/ojvjngv+Xg2fohW4Yg/DIjewXj13oi2oYjK9IjPoIhoUIS6gYBgwpBQ4J et24BxC5BNIYkU5IkOFQj49XiB3pkR8JkiEpkiNJkiVpkieJkimpkivJki3pki95kTEpkzNJ kzVpkzeJkzmpkzvJkz3pkz8JlEEplENJlEVplEeJlEmplEvJlE3/6ZRPCZVRKZVTSZVVaZVX iZVZqZVbyZVd6ZVfCZZhKZZjSZZlaZZniZZpqZZryZZt6ZZvCZdxKZdzSZd1aZd3iZd5qZd7 6ZUsIwjkc0orIEps+Sc90iczIph8GQM7Ain4AyNq8RWQaReKswqKuSBPQiK2kSVhQxpjsiV7 6ZeYCSSaKZrMYRiUYpmnmR9INCcsMzPHASgjcjeWKZs28iVcAiCFAiaDKZa1eSCmmSh9spkG AiJ3SSTqAZyqCSV2wjnOASGpGZqOyZqBgpuSiUSVqRqK4h1zkpr7cgO82Z01wZ0nAJ7hKQhJ Y57pqZ7ryZ7t6Z7vCZ/xKZ/zSZ/1aZ/3qYmf+amf+8mf/emf/wmgASqgUsk8homYEdMVBQOd H9IS44kegmID5dmXrWA15jE2FJov1+EmfcEwgQmXyfmcUAIiIIoI17EYDkqXbSEmxOk3SrGi 7REpL3qgdikegwQg6Fuyq4kj1lmYfMkYahKiA8QUroEjyDmcikmgCBKkJGoaSFGkVHKkNJqk S+qZD/qjpSk3UUqjVSOdgsGjQkOdfjKlfIIXpGSWBQAAOw== --=====================_RPTATT70413065.Exime-- From capwap-admin@frascone.com Tue Sep 13 14:46:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFFnR-0006CJ-D5 for capwap-archive@megatron.ietf.org; Tue, 13 Sep 2005 14:46:26 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05991 for ; Tue, 13 Sep 2005 14:46:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDC162051A; Tue, 13 Sep 2005 14:46:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CE01220513; Tue, 13 Sep 2005 14:46:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B0B2D20513 for ; Tue, 13 Sep 2005 14:45:51 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id 44A1E20510 for ; Tue, 13 Sep 2005 14:45:48 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8DIi4T6003595; Tue, 13 Sep 2005 13:44:04 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Sep 2005 20:44:03 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550808DE45@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Dan Harkins Cc: troy@twisted.net, capwap@frascone.com, dlang@cisco.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: IPR issues Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Sep 2005 20:44:02 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Well, you guys were debating potential IPR concerns, and so I figured I had to be clear that in accordance with the IETF IPR rules and the NOTE WELL statements, anyone who know about a patent needs to report on it if they participate. Best of course is if there are no IPR claims at all, but if they do exist, then we (as a WG) better know about them early. Bert > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com] > Sent: Tuesday, September 13, 2005 18:24 > To: Wijnen, Bert (Bert) > Cc: troy@twisted.net; capwap@frascone.com; dlang@cisco.com > Subject: Re: IPR issues > > > Bert, > > You overturned a rock and some nastly things crawled out. I > refer to: > > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-singh-capwap-ctp.txt > > So now Cisco is claiming IPR ON ALL SUBMISSIONS TO THIS > WORKING GROUP!!! > > How pathetic. And how utterly baseless. > > Dan. > > On Sat, 03 Sep 2005 23:06:28 +0200 you wrote > > All, > > > > I changed the subject line. > > This is not about FCC certification but about IPR. > > > > The question to be asked is: > > > > does anyone know if there is any IPR anywhere. > > > > According to the NOTE WELL, if anyone who contributes to > > or participates in this WG, then they MUST disclose if they know > > about any IPR of the technology being discussed in the WG. > > Even if it is IPR that they know someone else is holding. > > > > And so that includes all submitted technologies. > > Pls also read RFC 3978 and RFC 3979 > > > > Bert > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com]On > > > Behalf Of Dan Harkins > > > Sent: Saturday, September 03, 2005 13:47 > > > To: troy@twisted.net > > > Cc: capwap@frascone.com > > > Subject: [Capwap] this is not the thread on expanded discussion on > > > regulatory certification which has now officially ended > > > > > > > > > Troy, > > > > > > There is no IPR claim on SLAPP to remove. > > > > > > Dan. > > > > > > On Sat, 03 Sep 2005 08:28:56 CDT you wrote > > > > Guys, > > > > > > > > I've been watching the argument on this thread and feel > > > that it's time to > > > > make a statement as a working group member. There are two > > > very separate > > > > arguments going on here. One is related to IPR claims and > > > the other around > > > > image download and FCC violations. I am not making this > > > comment around the > > > > image download portion but believe it's essential to > > > discuss the IPR issue. > > > > > > > > I've seen the IPR game getting out of hand within the IETF > > > for way too long. > > > > There are way too many drafts that are coming into the IETF > > > standards > > > > process claiming IPR. > > > > > > > > The purpose for the CAPWAP working group is to create an > > > OPEN standard that > > > > all vendors can implement and show interoperability. > > > Regardless of the > > > > image download argument, before I'll stand up and back the > > > LWAPP or SLAPP > > > > contribution, I want Cisco as well as Trapeze to remove any > > > notion of owing > > > > IPR where they can go after other vendors that implement an > > > IETF standard. > > > > That simply does not wash. > > > > > > > > If the IPR comment stands then we as a working group must > > > engineer around > > > > any/all requirements and come up with a standard that does > > > not allow one > > > > vendor to have that type of power. > > > > > > > > I do not buy into any comments such as "we would never do > > > it" or "we want to > > > > contribute to this moving forward" etc. If that is the > > > case, drop the IPR > > > > claim and then we can go back to considering what protocol > > > would best > > > > represent the basis for CAPWAP. > > > > > > > > The notion of trying to move on from this topic and even > > > consider using a > > > > protocol that has this type of IPR claim is ridiculous > > > (IMHO). I want an > > > > IPR free protocol standard out of this group. > > > > > > > > So there are two questions. Will both the main authors of > > > each of the specs > > > > remove any/all IPR claims for consideration of being in the > > > spec? It's a > > > > simple question of yes or no. Please do not present a long > > > reply without > > > > answering it as a binary decision. > > > > > > > > -Troy > > > > > > > > > > > > > -----Original Message----- > > > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > > > Behalf Of Dan Harkins > > > > > Sent: Saturday, September 03, 2005 12:53 AM > > > > > To: Bob O'Hara (boohara) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > > certification > > > > > > > > > > Bob, > > > > > > > > > > On Fri, 02 Sep 2005 13:15:10 PDT you wrote > > > > > [snip] > > > > > > > > > > > > Both the SLAPP and LWAPP protocol proposals include the > > > ability to > > > > > download c > > > > > >ode to an AP/WTP. The difference between the two is > > > that CAPWAP requires > > > > > an a > > > > > >uthentication signature must be validated before a > > > download can be used, > > > > > while > > > > > > SLAPP has no such mechanism and specifically allows > > > download of code > > > > > from sou > > > > > >rces other than the manufacturer or an authorized > delegate of the > > > > > manufacturer > > > > > >. This is a significant difference between the two > > > protocols and needs > > > > > to be > > > > > >considered when evaluating the protocols during this > > > phase of selecting > > > > > the ba > > > > > >sis for CAPWAP standardization. > > > > > > > > > > "Both the SLAPP and LWAPP protocol proposals.... The > > > difference between > > > > > the > > > > > two is that CAPWAP requires an authentication signature > > > must be validated > > > > > before a download can be used, while SLAPP has no such > > > mechanism...." > > > > > > > > > > LWAPP = CAPWAP? I think you're getting a little excited > > > here Bob. Either > > > > > that or you know something that has not been made public yet. > > > > > > > > > > What you don't know is how SLAPP works. Please go read > > > the spec. There is > > > > > an authentication step PRIOR to the AC and WTP deciding > > > whether to proceed > > > > > to the full-fledged control and provisioning protocol or > > > to do image > > > > > download. > > > > > > > > > > > Going back to one of my first statements on this topic > > > and to bring this > > > > > arou > > > > > >nd again to why this discussion is important to the > > > working group while > > > > > evalua > > > > > >ting protocols, independent implementations of LWAPP can > > > be built from > > > > > the pro > > > > > >tocol specification, alone. That same statement cannot > > > be made about > > > > > SLAPP. > > > > > > > > > > Wrong! SLAPP includes a complete provisioning and control > > > protocol. > > > > > > > > > > Dan. > > > > > > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 13 20:59:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFLcG-0005gt-16 for capwap-archive@megatron.ietf.org; Tue, 13 Sep 2005 20:59:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13001 for ; Tue, 13 Sep 2005 20:59:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC26320540; Tue, 13 Sep 2005 20:59:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3711A1FFF2; Tue, 13 Sep 2005 20:59:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 30AC920540 for ; Tue, 13 Sep 2005 20:58:08 -0400 (EDT) Received: from staff-mail.rp.edu.sg (staff-mail.rp.edu.sg [202.21.158.80]) by mail.frascone.com (Postfix) with ESMTP id C150D1FFF2 for ; Tue, 13 Sep 2005 20:58:05 -0400 (EDT) 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 Message-ID: <9C374CF75527504394E573E1937136C401676789@staff-mail.rp.edu.sg> Thread-Topic: URL for CAPWAP Comparative Analysis Draft Thread-Index: AcW4k3mbeoUnL0UgSKK0gSTt2c/jQgAM4How From: "Richard Gwee" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] URL for CAPWAP Comparative Analysis Draft Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 14 Sep 2005 08:58:05 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, Below please find the URL for the CAPWAP Comparative Analysis Draft. http://www.ietf.org/internet-drafts/draft-gwee-capwap-comparative-analys is-00.txt Thanks and regards Richard Gwee _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 13 22:52:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFNNb-0004CN-R0 for capwap-archive@megatron.ietf.org; Tue, 13 Sep 2005 22:52:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18593 for ; Tue, 13 Sep 2005 22:52:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9320F1FFF2; Tue, 13 Sep 2005 22:52:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C50101FE04; Tue, 13 Sep 2005 22:52:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4F751FE02; Tue, 13 Sep 2005 22:51:13 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id BFEB21FC41; Tue, 13 Sep 2005 22:51:11 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 13 Sep 2005 19:51:11 -0700 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 j8E2oxKI010548; Tue, 13 Sep 2005 19:51:06 -0700 (PDT) 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); Tue, 13 Sep 2005 19:51:07 -0700 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] Re: In-band/out-of-band about the firmware download Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2A88590@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Re: In-band/out-of-band about the firmware download Thread-Index: AcW4Gyt4iw97Gqn5QqimH/g0OvDB3QAa84Mw From: "Pat Calhoun (pacalhou)" To: "zhaoyujin 00919" , Cc: X-OriginalArrivalTime: 14 Sep 2005 02:51:07.0426 (UTC) FILETIME=[27BF6020:01C5B8D7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Sep 2005 19:51:07 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Vendors should always be free to make changes to protocols, as long as the protocol allows for vendor extensions. That said, the WG needs to define a mandatory to implement mode - and if that is the case, I wonder why a vendor would feel compelled to support multiple methods. If the concern is that the mechanism defined by the WG is insufficient, then they should try to address that problem in the WG. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of zhaoyujin 00919 > Sent: Monday, September 12, 2005 9:24 PM > To: capwap-admin@frascone.com > Cc: capwap@frascone.com > Subject: [Capwap] Re: In-band/out-of-band about the firmware download >=20 > CAPWAP defines an architecture of WLAN. At present there are=20 > may realization protocols--LWAPP,SLAPP,CTP, and so on. >=20 > All those protocols use control tunnel and data tunnel. In=20 > one mail the next information is mentionned:"in-band=20 > mechanism(Download firmware with control tunnel)" and=20 > "out-of-band mechanism(Download firmware with other protocol=20 > like ftp,tftp)". And the mail give another mention--"perhaps=20 > a slightly more compicated state machine." >=20 > But in fact the out-of-band mechanism is not very compicated.=20 > If the capwap uses the out-of-band mechanism, the function=20 > will be clarified. >=20 > Can we add a payload in the version negotiation packet. This=20 > payload can decide the firmware download mechanism. For=20 > example the mechanism can use OUI+type. If the OUI is equal=20 > to 0x000000, capwap should think the download mechanism is=20 > common. Otherwise the mechanise is private for vendor. >=20 >=20 > Best regards > Michael >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 14 05:48:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFTsA-0003FF-J5 for capwap-archive@megatron.ietf.org; Wed, 14 Sep 2005 05:48:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01486 for ; Wed, 14 Sep 2005 05:48:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4DD99201F1; Wed, 14 Sep 2005 05:48:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6EB7D1FE11; Wed, 14 Sep 2005 05:48:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA77C1FE11 for ; Wed, 14 Sep 2005 05:47:53 -0400 (EDT) Received: from huawei-3com.com (smtp.huawei-3com.com [210.21.230.51]) by mail.frascone.com (Postfix) with ESMTP id 293DA1FE02 for ; Wed, 14 Sep 2005 05:47:50 -0400 (EDT) Received: from smtp.huawei-3com.com (localhost [127.0.0.1]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0IMS00LFVWFV9O@smtp.huawei-3com.com> for capwap@frascone.com; Wed, 14 Sep 2005 17:45:31 +0800 (CST) Received: from huawei-3com.com (ldapb.huawei-3com.com [172.19.1.228]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0IMS005SIWFUQ0@smtp.huawei-3com.com> for capwap@frascone.com; Wed, 14 Sep 2005 17:45:31 +0800 (CST) Received: from [10.18.1.7] by mail.huawei-3com.com (mshttpd); Wed, 14 Sep 2005 14:46:25 +0500 From: zhaoyujin 00919 Subject: =?gb2312?B?u9i4tA==?=:RE: [Capwap] Re: In-band/out-of-band about the firmware download To: "Pat Calhoun (pacalhou)" Cc: capwap@frascone.com Message-id: <1170313a9b.13a9b11703@huawei-3com.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) 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 AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 14 Sep 2005 14:46:25 +0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT I think capwap wants to define a control management of AP. And I think the WG has give some firmware download mechinasm which is enough for the capwap. But the firmware download is only a small part of the control management. And at present there are many file transimission protocol, capwap may think about using those protocol. If the vendor has not support any file transimission protocol, it can use the in-band firmware download. Otherwise the vendor may choose to negotiate which type download mechinasm. > Vendors should always be free to make changes to protocols, as > long as > the protocol allows for vendor extensions. That said, the WG needs to > define a mandatory to implement mode - and if that is the case, I > wonderwhy a vendor would feel compelled to support multiple > methods. If the > concern is that the mechanism defined by the WG is insufficient, then > they should try to address that problem in the WG. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [capwap-admin@frascone.com] On Behalf Of zhaoyujin 00919 > > Sent: Monday, September 12, 2005 9:24 PM > > To: capwap-admin@frascone.com > > Cc: capwap@frascone.com > > Subject: [Capwap] Re: In-band/out-of-band about the firmware > download> > > CAPWAP defines an architecture of WLAN. At present there are > > may realization protocols--LWAPP,SLAPP,CTP, and so on. > > > > All those protocols use control tunnel and data tunnel. In > > one mail the next information is mentionned:"in-band > > mechanism(Download firmware with control tunnel)" and > > "out-of-band mechanism(Download firmware with other protocol > > like ftp,tftp)". And the mail give another mention--"perhaps > > a slightly more compicated state machine." > > > > But in fact the out-of-band mechanism is not very compicated. > > If the capwap uses the out-of-band mechanism, the function > > will be clarified. > > > > Can we add a payload in the version negotiation packet. This > > payload can decide the firmware download mechanism. For > > example the mechanism can use OUI+type. If the OUI is equal > > to 0x000000, capwap should think the download mechanism is > > common. Otherwise the mechanise is private for vendor. > > > > > > Best regards > > Michael > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 14 07:19:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFVIJ-0006sN-5t for capwap-archive@megatron.ietf.org; Wed, 14 Sep 2005 07:19:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04678 for ; Wed, 14 Sep 2005 07:19:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A6E9201F1; Wed, 14 Sep 2005 07:19:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6C75F1FE11; Wed, 14 Sep 2005 07:19:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C8561FE11 for ; Wed, 14 Sep 2005 07:18:33 -0400 (EDT) Received: from oz.twisted.net (oz.twisted.net [69.211.34.241]) by mail.frascone.com (Postfix) with ESMTP id 9CA8D1FE02 for ; Wed, 14 Sep 2005 07:18:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by oz.twisted.net (Postfix) with ESMTP id 26A7E59909D for ; Wed, 14 Sep 2005 06:28:59 -0500 (CDT) Received: from oz.twisted.net ([127.0.0.1]) by localhost (oz.twisted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40577-07 for ; Wed, 14 Sep 2005 06:28:58 -0500 (CDT) Received: from noodle (sindrome.twisted.net [172.16.0.5]) by oz.twisted.net (Postfix) with ESMTP id 93814598F98 for ; Wed, 14 Sep 2005 06:28:46 -0500 (CDT) Reply-To: From: "Troy Dixler" To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW4lOLRdDBx2RP1R8CUQd/e/Q0ipQAiH/Eg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550808DE45@nl0006exch001u.nl.lucent.com> Message-Id: <20050914112846.93814598F98@oz.twisted.net> X-Virus-Scanned: by amavisd-new at twisted.net X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: IPR issues Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 14 Sep 2005 06:16:52 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Guys, I think that we have a major problem with this type of tactic. Clearly the working group has to move forward with submissions that are free from Cisco IPR claims. This type of hijacking of the working group simply cannot be permitted to take place. The IETF is an open standards working group. Talk about capitalism taken off the deep end. -Troy > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, September 13, 2005 1:44 PM > To: Dan Harkins > Cc: troy@twisted.net; capwap@frascone.com; dlang@cisco.com > Subject: RE: IPR issues > > Well, you guys were debating potential IPR concerns, and > so I figured I had to be clear that in accordance with the > IETF IPR rules and the NOTE WELL statements, anyone who > know about a patent needs to report on it if they participate. > > Best of course is if there are no IPR claims at all, but > if they do exist, then we (as a WG) better know about > them early. > > Bert > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com] > > Sent: Tuesday, September 13, 2005 18:24 > > To: Wijnen, Bert (Bert) > > Cc: troy@twisted.net; capwap@frascone.com; dlang@cisco.com > > Subject: Re: IPR issues > > > > > > Bert, > > > > You overturned a rock and some nastly things crawled out. I > > refer to: > > > > > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-singh-capwap-ctp.txt > > > > So now Cisco is claiming IPR ON ALL SUBMISSIONS TO THIS > > WORKING GROUP!!! > > > > How pathetic. And how utterly baseless. > > > > Dan. > > > > On Sat, 03 Sep 2005 23:06:28 +0200 you wrote > > > All, > > > > > > I changed the subject line. > > > This is not about FCC certification but about IPR. > > > > > > The question to be asked is: > > > > > > does anyone know if there is any IPR anywhere. > > > > > > According to the NOTE WELL, if anyone who contributes to > > > or participates in this WG, then they MUST disclose if they know > > > about any IPR of the technology being discussed in the WG. > > > Even if it is IPR that they know someone else is holding. > > > > > > And so that includes all submitted technologies. > > > Pls also read RFC 3978 and RFC 3979 > > > > > > Bert > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com]On > > > > Behalf Of Dan Harkins > > > > Sent: Saturday, September 03, 2005 13:47 > > > > To: troy@twisted.net > > > > Cc: capwap@frascone.com > > > > Subject: [Capwap] this is not the thread on expanded discussion on > > > > regulatory certification which has now officially ended > > > > > > > > > > > > Troy, > > > > > > > > There is no IPR claim on SLAPP to remove. > > > > > > > > Dan. > > > > > > > > On Sat, 03 Sep 2005 08:28:56 CDT you wrote > > > > > Guys, > > > > > > > > > > I've been watching the argument on this thread and feel > > > > that it's time to > > > > > make a statement as a working group member. There are two > > > > very separate > > > > > arguments going on here. One is related to IPR claims and > > > > the other around > > > > > image download and FCC violations. I am not making this > > > > comment around the > > > > > image download portion but believe it's essential to > > > > discuss the IPR issue. > > > > > > > > > > I've seen the IPR game getting out of hand within the IETF > > > > for way too long. > > > > > There are way too many drafts that are coming into the IETF > > > > standards > > > > > process claiming IPR. > > > > > > > > > > The purpose for the CAPWAP working group is to create an > > > > OPEN standard that > > > > > all vendors can implement and show interoperability. > > > > Regardless of the > > > > > image download argument, before I'll stand up and back the > > > > LWAPP or SLAPP > > > > > contribution, I want Cisco as well as Trapeze to remove any > > > > notion of owing > > > > > IPR where they can go after other vendors that implement an > > > > IETF standard. > > > > > That simply does not wash. > > > > > > > > > > If the IPR comment stands then we as a working group must > > > > engineer around > > > > > any/all requirements and come up with a standard that does > > > > not allow one > > > > > vendor to have that type of power. > > > > > > > > > > I do not buy into any comments such as "we would never do > > > > it" or "we want to > > > > > contribute to this moving forward" etc. If that is the > > > > case, drop the IPR > > > > > claim and then we can go back to considering what protocol > > > > would best > > > > > represent the basis for CAPWAP. > > > > > > > > > > The notion of trying to move on from this topic and even > > > > consider using a > > > > > protocol that has this type of IPR claim is ridiculous > > > > (IMHO). I want an > > > > > IPR free protocol standard out of this group. > > > > > > > > > > So there are two questions. Will both the main authors of > > > > each of the specs > > > > > remove any/all IPR claims for consideration of being in the > > > > spec? It's a > > > > > simple question of yes or no. Please do not present a long > > > > reply without > > > > > answering it as a binary decision. > > > > > > > > > > -Troy > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On > > > > > > Behalf Of Dan Harkins > > > > > > Sent: Saturday, September 03, 2005 12:53 AM > > > > > > To: Bob O'Hara (boohara) > > > > > > Cc: capwap@frascone.com > > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > > > certification > > > > > > > > > > > > Bob, > > > > > > > > > > > > On Fri, 02 Sep 2005 13:15:10 PDT you wrote > > > > > > [snip] > > > > > > > > > > > > > > Both the SLAPP and LWAPP protocol proposals include the > > > > ability to > > > > > > download c > > > > > > >ode to an AP/WTP. The difference between the two is > > > > that CAPWAP requires > > > > > > an a > > > > > > >uthentication signature must be validated before a > > > > download can be used, > > > > > > while > > > > > > > SLAPP has no such mechanism and specifically allows > > > > download of code > > > > > > from sou > > > > > > >rces other than the manufacturer or an authorized > > delegate of the > > > > > > manufacturer > > > > > > >. This is a significant difference between the two > > > > protocols and needs > > > > > > to be > > > > > > >considered when evaluating the protocols during this > > > > phase of selecting > > > > > > the ba > > > > > > >sis for CAPWAP standardization. > > > > > > > > > > > > "Both the SLAPP and LWAPP protocol proposals.... The > > > > difference between > > > > > > the > > > > > > two is that CAPWAP requires an authentication signature > > > > must be validated > > > > > > before a download can be used, while SLAPP has no such > > > > mechanism...." > > > > > > > > > > > > LWAPP = CAPWAP? I think you're getting a little excited > > > > here Bob. Either > > > > > > that or you know something that has not been made public yet. > > > > > > > > > > > > What you don't know is how SLAPP works. Please go read > > > > the spec. There is > > > > > > an authentication step PRIOR to the AC and WTP deciding > > > > whether to proceed > > > > > > to the full-fledged control and provisioning protocol or > > > > to do image > > > > > > download. > > > > > > > > > > > > > Going back to one of my first statements on this topic > > > > and to bring this > > > > > > arou > > > > > > >nd again to why this discussion is important to the > > > > working group while > > > > > > evalua > > > > > > >ting protocols, independent implementations of LWAPP can > > > > be built from > > > > > > the pro > > > > > > >tocol specification, alone. That same statement cannot > > > > be made about > > > > > > SLAPP. > > > > > > > > > > > > Wrong! SLAPP includes a complete provisioning and control > > > > protocol. > > > > > > > > > > > > Dan. > > > > > > > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From Safonov@norikomail.com Wed Sep 14 08:11:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFW7K-0001XT-3J for capwap-archive@megatron.ietf.org; Wed, 14 Sep 2005 08:11:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06925 for ; Wed, 14 Sep 2005 08:11:56 -0400 (EDT) Received: from [85.99.197.77] (helo=mindspring.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFWBr-00009p-AG for capwap-archive@ietf.org; Wed, 14 Sep 2005 08:16:43 -0400 From: "Shaminov Bakyt" To: "Narius Mark" Subject: Re[6]: Date: Wed, 14 Sep 2005 12:11:55 +0000 Message-ID: <0a5401c5b925$0415ddb3$54007977@mindspring.com> X-SA-Do-Not-Rej: Yes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_7A89_B53D40CE.1F627A89" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1441 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Antivirus: avast! (VPS 0537-0, 12.09.2005), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_7A89_B53D40CE.1F627A89 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SPUR-m [Sperm pills] - because it works. Go on, give it a try. You'll sure enjoy it! SPUR-m [Cum pills]: http://brachia.com/ Discreet, unmarked packaging. >>> NB: No prescription required ------=_NextPart_000_7A89_B53D40CE.1F627A89 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SPUR-m [Sperm pills] - because it works.
 
Go on, give it a try. = You'll sure=20 enjoy it!
SPUR-m [Cum pills]: http://brachia.com/
 
Discreet, unmarked=20 packaging.
 
>>> NB: No = prescription=20 required
------=_NextPart_000_7A89_B53D40CE.1F627A89-- From capwap-admin@frascone.com Wed Sep 14 11:38:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZKw-0000bD-8U for capwap-archive@megatron.ietf.org; Wed, 14 Sep 2005 11:38:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17481 for ; Wed, 14 Sep 2005 11:38:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A010420415; Wed, 14 Sep 2005 11:38:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B769B202A8; Wed, 14 Sep 2005 11:38:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE86F202A8 for ; Wed, 14 Sep 2005 11:37:16 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id D7EE52024F for ; Wed, 14 Sep 2005 11:37:11 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 08:41:18 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Sep 2005 08:36:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5B942.2488189D" Message-ID: Thread-Topic: Evaluation Team draft submitted Thread-Index: AcW5QiPIhf3nEv8mS9+Ud/GDm2fnBg== From: "Darren Loher" To: X-OriginalArrivalTime: 14 Sep 2005 15:36:59.0610 (UTC) FILETIME=[256233A0:01C5B942] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Evaluation Team draft submitted Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 14 Sep 2005 08:36:56 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5B942.2488189D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The evaluation team draft was submitted last night to internet-drafts@ietf.org. It should appear in the Internet Drafts soon as: =20 draft-ietf-capwap-eval-00.txt =20 =20 -- Darren Loher Roving Planet =20 http://www.rovingplanet.com +1.303.996.7578 =20 ------_=_NextPart_001_01C5B942.2488189D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The evaluation team draft was submitted last night to = internet-drafts@ietf.org.&nb= sp; It should appear in the Internet Drafts soon as:

 

draft-ietf-capwap-eval-00.txt=

 

 

--

Darren Loher

Roving Planet 

http://www.rov= ingplanet.com

+1.303.996.7578

 

------_=_NextPart_001_01C5B942.2488189D-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 14 11:59:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFZfD-0005DR-R6 for capwap-archive@megatron.ietf.org; Wed, 14 Sep 2005 11:59:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18626 for ; Wed, 14 Sep 2005 11:59:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D302D20454; Wed, 14 Sep 2005 11:59:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 801C320429; Wed, 14 Sep 2005 11:59:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AEAE020429 for ; Wed, 14 Sep 2005 11:58:13 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by mail.frascone.com (Postfix) with ESMTP id 52AEA20415 for ; Wed, 14 Sep 2005 11:58:09 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8EFsxfU022513; Wed, 14 Sep 2005 18:55:01 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Sep 2005 18:56:06 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Sep 2005 10:56:01 -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: FW: [Capwap] Evaluation Team draft submitted Message-ID: <893AE265F4ADF94AB7FB26D31A788E41FBD791@mvebe101.NOE.Nokia.com> Thread-Topic: [Capwap] Evaluation Team draft submitted Thread-Index: AcW5QiPIhf3nEv8mS9+Ud/GDm2fnBgAAcHCQ From: To: Cc: , X-OriginalArrivalTime: 14 Sep 2005 15:56:01.0949 (UTC) FILETIME=[CE454CD0:01C5B944] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 14 Sep 2005 08:55:59 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The CAPWAP evaluation team has completed its recommendation. Unless anyone objectss the WG chairs propose to accept the=20 draft as a WG document. This does not mean that the recommendation is accepted by the WG. =20 We will still have to agree as a WG on the protocol recommendation. =20 Regards, WG Chairs ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of ext Darren Loher Sent: Wednesday, September 14, 2005 8:37 AM To: capwap@frascone.com Subject: [Capwap] Evaluation Team draft submitted The evaluation team draft was submitted last night to internet-drafts@ietf.org. It should appear in the Internet Drafts soon as: =20 draft-ietf-capwap-eval-00.txt =20 =20 -- Darren Loher Roving Planet =20 http://www.rovingplanet.com +1.303.996.7578 =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 14 12:31:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFaAB-00064I-Ub for capwap-archive@megatron.ietf.org; Wed, 14 Sep 2005 12:31:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20054 for ; Wed, 14 Sep 2005 12:31:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3AD682043C; Wed, 14 Sep 2005 12:31:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B06E20370; Wed, 14 Sep 2005 12:31:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E72E320370 for ; Wed, 14 Sep 2005 12:30:38 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by mail.frascone.com (Postfix) with ESMTP id D8E3D20254 for ; Wed, 14 Sep 2005 12:30:36 -0400 (EDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8EGQpsx031208; Wed, 14 Sep 2005 19:27:00 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Sep 2005 19:28:41 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Sep 2005 11:28:28 -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 Message-ID: <893AE265F4ADF94AB7FB26D31A788E41FBD7D1@mvebe101.NOE.Nokia.com> Thread-Topic: IPR disclosures releated to the CAPWAP WG Thread-Index: AcW4fFSgWEklqJAnQ2iPA6u/zo+S9wAyhKvw From: To: Cc: , , X-OriginalArrivalTime: 14 Sep 2005 16:28:28.0399 (UTC) FILETIME=[5671FFF0:01C5B949] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IPR disclosures releated to the CAPWAP WG Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 14 Sep 2005 09:28:26 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable =20 Yesterday we received the following IPR notification from the IETF Secretariat. In addtion,=20 there is another other claim that may be related to the CAPWAP WG: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D144 We have no other information at the time. We suggest the WG review the claims and discuss their impact on the list. The IPR IETF disclosure page can be found at https://datatracker.ietf.org/public/ipr_disclosure.cgi Regards, WG Chairs -----Original Message----- From: Apache [mailto:apache@newodin.ietf.org] On Behalf Of ext IETF Secretariat Sent: Tuesday, September 13, 2005 9:00 AM To: partha@arubanetworks.com Cc: bwijnen@lucent.com; mmani@avaya.com; Gellert Dorothy (Nokia-ES/MtView) Subject: Posting of IPR Disclosure Dear Partha Narasimhan: An IPR disclosure that pertains to your Internet-Draft entitled "SLAPP : Secure Light Access Point Protocol" (draft-narasimhan-ietf-slapp) was submitted to the IETF Secretariat on 2005-09-07 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Cisco's Statement about IPR claimed in draft-singh-capwap-ctp-02.txt, draft-iino-capwap-wicop-02.txt, internet-drafts/draft-narasimhan-ietf-slapp-01.txt." The IETF Secretariat _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From Roadruck@smapxsmap.net Wed Sep 14 14:10:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFbiH-0005ym-3V for capwap-archive@megatron.ietf.org; Wed, 14 Sep 2005 14:10:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24432 for ; Wed, 14 Sep 2005 14:10:27 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFbmp-0000gg-2w for capwap-archive@ietf.org; Wed, 14 Sep 2005 14:15:17 -0400 Received: from [200.179.154.218] (helo=sanriotown.com) by mx2.foretec.com with smtp (Exim 4.24) id 1EFaq1-0001yF-TA for capwap-archive@ietf.org; Wed, 14 Sep 2005 13:14:26 -0400 From: "Hartley Peter" To: "Lalonde Yves" Subject: Re[3]: Date: Wed, 14 Sep 2005 18:10:21 +0000 Message-ID: <2b0701c5b957$195667d7$54007977@sanriotown.com> X-SA-Do-Not-Rej: Yes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_B53D_40CE1F62.7A89B53D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 1.6 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_B53D_40CE1F62.7A89B53D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Take MORE-SIZE and be Superman! Go on, give it a try. You'll sure enjoy it! MORE-SIZE: http://efficacies.net/more/ Discreet, unmarked packaging. >>> NB: No prescription required ------=_NextPart_000_B53D_40CE1F62.7A89B53D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Take MORE-SIZE and be Superman!
 
Go on, give it a try. = You'll sure=20 enjoy it!
MORE-SIZE: http://efficacies.net/more/
 
Discreet, unmarked=20 packaging.
 
>>> NB: No = prescription=20 required
------=_NextPart_000_B53D_40CE1F62.7A89B53D-- From capwap-admin@frascone.com Wed Sep 14 19:33:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFgkb-0000VO-0a for capwap-archive@megatron.ietf.org; Wed, 14 Sep 2005 19:33:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19288 for ; Wed, 14 Sep 2005 19:33:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 32AC31FC28; Wed, 14 Sep 2005 19:33:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 548BC1FC41; Wed, 14 Sep 2005 19:33:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB1581FC41 for ; Wed, 14 Sep 2005 19:32:19 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id A5C181FC28 for ; Wed, 14 Sep 2005 19:32:17 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 16:36:14 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 16:32:00 -0700 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] RE: IPR issues Message-ID: Thread-Topic: [Capwap] RE: IPR issues Thread-Index: AcW4lOLRdDBx2RP1R8CUQd/e/Q0ipQAiH/EgABYoUEA= From: "Darren Loher" To: , X-OriginalArrivalTime: 14 Sep 2005 23:32:00.0455 (UTC) FILETIME=[81360570:01C5B984] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 14 Sep 2005 16:31:54 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I definitely agree that this is a major problem and poses a major barrier to adoption of a standard. =20 It might help if we knew what was being claimed. This might help us have a discussion about how to deal with the problem. However, since the patent application(s) in question are unpublished it is difficult to do so. =20 The act of requiring a license, even if free, to implement an Internet RFC will pose major problems for some implementers. I respect that Cisco would like to protect themselves from litigation, but this does not sound like a merely protective measure. The latest disclosure specifies that licensing is conditional and is not a free, unconditional license. In order to be successful, whatever this working group creates and emerges as the CAPWAP protocol must be free of licensing requirements. -Darren > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Troy Dixler > Sent: Wednesday, September 14, 2005 5:17 AM > To: capwap@frascone.com > Subject: [Capwap] RE: IPR issues >=20 > Guys, >=20 > I think that we have a major problem with this type of tactic. Clearly the > working group has to move forward with submissions that are free from > Cisco > IPR claims. This type of hijacking of the working group simply cannot be > permitted to take place. The IETF is an open standards working group. Talk > about capitalism taken off the deep end. >=20 > -Troy >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Tuesday, September 13, 2005 1:44 PM > > To: Dan Harkins > > Cc: troy@twisted.net; capwap@frascone.com; dlang@cisco.com > > Subject: RE: IPR issues > > > > Well, you guys were debating potential IPR concerns, and > > so I figured I had to be clear that in accordance with the > > IETF IPR rules and the NOTE WELL statements, anyone who > > know about a patent needs to report on it if they participate. > > > > Best of course is if there are no IPR claims at all, but > > if they do exist, then we (as a WG) better know about > > them early. > > > > Bert > > > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Tuesday, September 13, 2005 18:24 > > > To: Wijnen, Bert (Bert) > > > Cc: troy@twisted.net; capwap@frascone.com; dlang@cisco.com > > > Subject: Re: IPR issues > > > > > > > > > Bert, > > > > > > You overturned a rock and some nastly things crawled out. I > > > refer to: > > > > > > > > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-singh-capwap-ctp.txt > > > > > > So now Cisco is claiming IPR ON ALL SUBMISSIONS TO THIS > > > WORKING GROUP!!! > > > > > > How pathetic. And how utterly baseless. > > > > > > Dan. > > > > > > On Sat, 03 Sep 2005 23:06:28 +0200 you wrote > > > > All, > > > > > > > > I changed the subject line. > > > > This is not about FCC certification but about IPR. > > > > > > > > The question to be asked is: > > > > > > > > does anyone know if there is any IPR anywhere. > > > > > > > > According to the NOTE WELL, if anyone who contributes to > > > > or participates in this WG, then they MUST disclose if they know > > > > about any IPR of the technology being discussed in the WG. > > > > Even if it is IPR that they know someone else is holding. > > > > > > > > And so that includes all submitted technologies. > > > > Pls also read RFC 3978 and RFC 3979 > > > > > > > > Bert > > > > > > > > > -----Original Message----- > > > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com]On > > > > > Behalf Of Dan Harkins > > > > > Sent: Saturday, September 03, 2005 13:47 > > > > > To: troy@twisted.net > > > > > Cc: capwap@frascone.com > > > > > Subject: [Capwap] this is not the thread on expanded discussion on > > > > > regulatory certification which has now officially ended > > > > > > > > > > > > > > > Troy, > > > > > > > > > > There is no IPR claim on SLAPP to remove. > > > > > > > > > > Dan. > > > > > > > > > > On Sat, 03 Sep 2005 08:28:56 CDT you wrote > > > > > > Guys, > > > > > > > > > > > > I've been watching the argument on this thread and feel > > > > > that it's time to > > > > > > make a statement as a working group member. There are two > > > > > very separate > > > > > > arguments going on here. One is related to IPR claims and > > > > > the other around > > > > > > image download and FCC violations. I am not making this > > > > > comment around the > > > > > > image download portion but believe it's essential to > > > > > discuss the IPR issue. > > > > > > > > > > > > I've seen the IPR game getting out of hand within the IETF > > > > > for way too long. > > > > > > There are way too many drafts that are coming into the IETF > > > > > standards > > > > > > process claiming IPR. > > > > > > > > > > > > The purpose for the CAPWAP working group is to create an > > > > > OPEN standard that > > > > > > all vendors can implement and show interoperability. > > > > > Regardless of the > > > > > > image download argument, before I'll stand up and back the > > > > > LWAPP or SLAPP > > > > > > contribution, I want Cisco as well as Trapeze to remove any > > > > > notion of owing > > > > > > IPR where they can go after other vendors that implement an > > > > > IETF standard. > > > > > > That simply does not wash. > > > > > > > > > > > > If the IPR comment stands then we as a working group must > > > > > engineer around > > > > > > any/all requirements and come up with a standard that does > > > > > not allow one > > > > > > vendor to have that type of power. > > > > > > > > > > > > I do not buy into any comments such as "we would never do > > > > > it" or "we want to > > > > > > contribute to this moving forward" etc. If that is the > > > > > case, drop the IPR > > > > > > claim and then we can go back to considering what protocol > > > > > would best > > > > > > represent the basis for CAPWAP. > > > > > > > > > > > > The notion of trying to move on from this topic and even > > > > > consider using a > > > > > > protocol that has this type of IPR claim is ridiculous > > > > > (IMHO). I want an > > > > > > IPR free protocol standard out of this group. > > > > > > > > > > > > So there are two questions. Will both the main authors of > > > > > each of the specs > > > > > > remove any/all IPR claims for consideration of being in the > > > > > spec? It's a > > > > > > simple question of yes or no. Please do not present a long > > > > > reply without > > > > > > answering it as a binary decision. > > > > > > > > > > > > -Troy > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: capwap-admin@frascone.com > > > > > [mailto:capwap-admin@frascone.com] On > > > > > > > Behalf Of Dan Harkins > > > > > > > Sent: Saturday, September 03, 2005 12:53 AM > > > > > > > To: Bob O'Hara (boohara) > > > > > > > Cc: capwap@frascone.com > > > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > > > > certification > > > > > > > > > > > > > > Bob, > > > > > > > > > > > > > > On Fri, 02 Sep 2005 13:15:10 PDT you wrote > > > > > > > [snip] > > > > > > > > > > > > > > > > Both the SLAPP and LWAPP protocol proposals include the > > > > > ability to > > > > > > > download c > > > > > > > >ode to an AP/WTP. The difference between the two is > > > > > that CAPWAP requires > > > > > > > an a > > > > > > > >uthentication signature must be validated before a > > > > > download can be used, > > > > > > > while > > > > > > > > SLAPP has no such mechanism and specifically allows > > > > > download of code > > > > > > > from sou > > > > > > > >rces other than the manufacturer or an authorized > > > delegate of the > > > > > > > manufacturer > > > > > > > >. This is a significant difference between the two > > > > > protocols and needs > > > > > > > to be > > > > > > > >considered when evaluating the protocols during this > > > > > phase of selecting > > > > > > > the ba > > > > > > > >sis for CAPWAP standardization. > > > > > > > > > > > > > > "Both the SLAPP and LWAPP protocol proposals.... The > > > > > difference between > > > > > > > the > > > > > > > two is that CAPWAP requires an authentication signature > > > > > must be validated > > > > > > > before a download can be used, while SLAPP has no such > > > > > mechanism...." > > > > > > > > > > > > > > LWAPP =3D CAPWAP? I think you're getting a little excited > > > > > here Bob. Either > > > > > > > that or you know something that has not been made public yet. > > > > > > > > > > > > > > What you don't know is how SLAPP works. Please go read > > > > > the spec. There is > > > > > > > an authentication step PRIOR to the AC and WTP deciding > > > > > whether to proceed > > > > > > > to the full-fledged control and provisioning protocol or > > > > > to do image > > > > > > > download. > > > > > > > > > > > > > > > Going back to one of my first statements on this topic > > > > > and to bring this > > > > > > > arou > > > > > > > >nd again to why this discussion is important to the > > > > > working group while > > > > > > > evalua > > > > > > > >ting protocols, independent implementations of LWAPP can > > > > > be built from > > > > > > > the pro > > > > > > > >tocol specification, alone. That same statement cannot > > > > > be made about > > > > > > > SLAPP. > > > > > > > > > > > > > > Wrong! SLAPP includes a complete provisioning and control > > > > > protocol. > > > > > > > > > > > > > > Dan. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Capwap mailing list > > > > > > > Capwap@frascone.com > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 14 23:21:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFkJD-0000AH-FF for capwap-archive@megatron.ietf.org; Wed, 14 Sep 2005 23:21:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00134 for ; Wed, 14 Sep 2005 23:21:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 88EEE1FC41; Wed, 14 Sep 2005 23:21:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 41EAE1FE02; Wed, 14 Sep 2005 23:21:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 83E541FE02 for ; Wed, 14 Sep 2005 23:20:07 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 893DD1FC41 for ; Wed, 14 Sep 2005 23:20:02 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 14 Sep 2005 20:20:02 -0700 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 j8F3Jw4u010147; Wed, 14 Sep 2005 20:19:59 -0700 (PDT) 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, 14 Sep 2005 20:19:50 -0700 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="GB2312" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: [Capwap] Re: In-band/out-of-band about the firmware download Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2A88B35@xmb-sjc-235.amer.cisco.com> Thread-Topic: RE: [Capwap] Re: In-band/out-of-band about the firmware download Thread-Index: AcW5EYE0NdmE4jMVRbWW2X68JIy/mgAcUoEg From: "Pat Calhoun [pacalhou@cisco.com]" To: "zhaoyujin 00919" Cc: X-OriginalArrivalTime: 15 Sep 2005 03:19:50.0339 (UTC) FILETIME=[5518C930:01C5B9A4] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 14 Sep 2005 20:19:49 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable But once more this introduces optional download mechanisms, which means = interoperability issues. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: zhaoyujin 00919 [mailto:zhaoyujin@huawei-3com.com]=20 > Sent: Wednesday, September 14, 2005 2:46 AM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: =BB=D8=B8=B4:RE: [Capwap] Re: In-band/out-of-band about the=20 > firmware download >=20 > I think capwap wants to define a control management of AP.=20 > And I think the WG has give some firmware download mechinasm=20 > which is enough for the capwap. >=20 > But the firmware download is only a small part of the control=20 > management. And at present there are many file transimission=20 > protocol, capwap may think about using those protocol. >=20 > If the vendor has not support any file transimission=20 > protocol, it can use the in-band firmware download. Otherwise=20 > the vendor may choose to negotiate which type download mechinasm. >=20 >=20 >=20 > > Vendors should always be free to make changes to protocols,=20 > as long as=20 > > the protocol allows for vendor extensions. That said, the=20 > WG needs to=20 > > define a mandatory to implement mode - and if that is the case, I=20 > > wonderwhy a vendor would feel compelled to support multiple=20 > methods.=20 > > If the concern is that the mechanism defined by the WG is=20 > > insufficient, then they should try to address that problem=20 > in the WG. > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [capwap-admin@frascone.com] On Behalf Of zhaoyujin 00919 > > > Sent: Monday, September 12, 2005 9:24 PM > > > To: capwap-admin@frascone.com > > > Cc: capwap@frascone.com > > > Subject: [Capwap] Re: In-band/out-of-band about the firmware > > download>=20 > > > CAPWAP defines an architecture of WLAN. At present there are may=20 > > > realization protocols--LWAPP,SLAPP,CTP, and so on. > > >=20 > > > All those protocols use control tunnel and data tunnel.=20 > In one mail=20 > > > the next information is mentionned:"in-band mechanism(Download=20 > > > firmware with control tunnel)" and "out-of-band=20 > mechanism(Download=20 > > > firmware with other protocol like ftp,tftp)". And the mail give=20 > > > another mention--"perhaps a slightly more compicated=20 > state machine." > > >=20 > > > But in fact the out-of-band mechanism is not very compicated.=20 > > > If the capwap uses the out-of-band mechanism, the=20 > function will be=20 > > > clarified. > > >=20 > > > Can we add a payload in the version negotiation packet.=20 > This payload=20 > > > can decide the firmware download mechanism. For example the=20 > > > mechanism can use OUI+type. If the OUI is equal to=20 > 0x000000, capwap=20 > > > should think the download mechanism is common. Otherwise the=20 > > > mechanise is private for vendor. > > >=20 > > >=20 > > > Best regards > > > Michael > > >=20 > > >=20 > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > >=20 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From Cibolka@allergist.com Thu Sep 15 00:07:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFl1e-0002gB-4D for capwap-archive@megatron.ietf.org; Thu, 15 Sep 2005 00:07:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01785 for ; Thu, 15 Sep 2005 00:07:03 -0400 (EDT) Received: from 200164051127.user.veloxzone.com.br ([200.164.51.127] helo=169.cc) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFl6L-0002SJ-TX for capwap-archive@ietf.org; Thu, 15 Sep 2005 00:12:00 -0400 From: "Strotkamp Michael" To: "Isaacs Rachel" Subject: Re[9]: Date: Thu, 15 Sep 2005 04:07:01 +0000 Message-ID: <4d8501c5b9aa$2bcfbbdf$54007977@169.cc> X-SA-Do-Not-Rej: Yes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_B53D_40CE1F62.7A89B53D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 2.8 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_B53D_40CE1F62.7A89B53D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Get ready for sexual overdrive! Go on, give it a try. You'll sure enjoy it! Cialis Softtabs: http://unglazed.net/now/ Discreet, unmarked packaging. >>> NB: No prescription required ------=_NextPart_000_B53D_40CE1F62.7A89B53D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Get ready for sexual overdrive!
 
Go on, give it a try. = You'll sure=20 enjoy it!
Cialis Softtabs: http://unglazed.net/now/
 
Discreet, unmarked=20 packaging.
 
>>> NB: No = prescription=20 required
------=_NextPart_000_B53D_40CE1F62.7A89B53D-- From capwap-admin@frascone.com Thu Sep 15 06:17:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFqno-0004BZ-Qg for capwap-archive@megatron.ietf.org; Thu, 15 Sep 2005 06:17:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01656 for ; Thu, 15 Sep 2005 06:17:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4A3E12038A; Thu, 15 Sep 2005 06:17:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 93A1620295; Thu, 15 Sep 2005 06:17:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E986120295 for ; Thu, 15 Sep 2005 06:16:25 -0400 (EDT) Received: from oz.twisted.net (oz.twisted.net [69.211.34.241]) by mail.frascone.com (Postfix) with ESMTP id B46D71FD63 for ; Thu, 15 Sep 2005 06:16:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by oz.twisted.net (Postfix) with ESMTP id 4AFC5599C91 for ; Thu, 15 Sep 2005 05:26:55 -0500 (CDT) Received: from oz.twisted.net ([127.0.0.1]) by localhost (oz.twisted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56782-02 for ; Thu, 15 Sep 2005 05:26:54 -0500 (CDT) Received: from noodle (sindrome.twisted.net [172.16.0.5]) by oz.twisted.net (Postfix) with ESMTP id C59C559904C for ; Thu, 15 Sep 2005 05:26:42 -0500 (CDT) Reply-To: From: "Troy Dixler" To: Subject: RE: [Capwap] RE: IPR issues MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW4lOLRdDBx2RP1R8CUQd/e/Q0ipQAiH/EgABYoUEAAGerZIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: Message-Id: <20050915102642.C59C559904C@oz.twisted.net> X-Virus-Scanned: by amavisd-new at twisted.net X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 15 Sep 2005 05:14:40 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I'd like to hear from the WG chairs on this matter as this presents a problem for the mission and charter of the group. I would imagine that other WG chairs or Area directors have faced similar challenges and we need to move forward. One easy way we can address these issues outright is to take a mailing list vote around accepting the drafts that have been presented to this working group that have IPR claims and not allow them to become working group items. Let's hear the WG chairs on this issue. -Troy > -----Original Message----- > From: Darren Loher [mailto:DLoher@rovingplanet.com] > Sent: Wednesday, September 14, 2005 6:32 PM > To: troy@twisted.net; capwap@frascone.com > Subject: RE: [Capwap] RE: IPR issues > > I definitely agree that this is a major problem and poses a major > barrier to adoption of a standard. > > It might help if we knew what was being claimed. This might help us > have a discussion about how to deal with the problem. However, since > the patent application(s) in question are unpublished it is difficult to > do so. > > The act of requiring a license, even if free, to implement an Internet > RFC will pose major problems for some implementers. I respect that > Cisco would like to protect themselves from litigation, but this does > not sound like a merely protective measure. The latest disclosure > specifies that licensing is conditional and is not a free, unconditional > license. > > In order to be successful, whatever this working group creates and > emerges as the CAPWAP protocol must be free of licensing requirements. > > > -Darren > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Troy Dixler > > Sent: Wednesday, September 14, 2005 5:17 AM > > To: capwap@frascone.com > > Subject: [Capwap] RE: IPR issues > > > > Guys, > > > > I think that we have a major problem with this type of tactic. Clearly > the > > working group has to move forward with submissions that are free from > > Cisco > > IPR claims. This type of hijacking of the working group simply cannot > be > > permitted to take place. The IETF is an open standards working group. > Talk > > about capitalism taken off the deep end. > > > > -Troy > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Tuesday, September 13, 2005 1:44 PM > > > To: Dan Harkins > > > Cc: troy@twisted.net; capwap@frascone.com; dlang@cisco.com > > > Subject: RE: IPR issues > > > > > > Well, you guys were debating potential IPR concerns, and > > > so I figured I had to be clear that in accordance with the > > > IETF IPR rules and the NOTE WELL statements, anyone who > > > know about a patent needs to report on it if they participate. > > > > > > Best of course is if there are no IPR claims at all, but > > > if they do exist, then we (as a WG) better know about > > > them early. > > > > > > Bert > > > > > > > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > > Sent: Tuesday, September 13, 2005 18:24 > > > > To: Wijnen, Bert (Bert) > > > > Cc: troy@twisted.net; capwap@frascone.com; dlang@cisco.com > > > > Subject: Re: IPR issues > > > > > > > > > > > > Bert, > > > > > > > > You overturned a rock and some nastly things crawled out. I > > > > refer to: > > > > > > > > > > > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-singh-capwap-ctp.txt > > > > > > > > So now Cisco is claiming IPR ON ALL SUBMISSIONS TO THIS > > > > WORKING GROUP!!! > > > > > > > > How pathetic. And how utterly baseless. > > > > > > > > Dan. > > > > > > > > On Sat, 03 Sep 2005 23:06:28 +0200 you wrote > > > > > All, > > > > > > > > > > I changed the subject line. > > > > > This is not about FCC certification but about IPR. > > > > > > > > > > The question to be asked is: > > > > > > > > > > does anyone know if there is any IPR anywhere. > > > > > > > > > > According to the NOTE WELL, if anyone who contributes to > > > > > or participates in this WG, then they MUST disclose if they know > > > > > about any IPR of the technology being discussed in the WG. > > > > > Even if it is IPR that they know someone else is holding. > > > > > > > > > > And so that includes all submitted technologies. > > > > > Pls also read RFC 3978 and RFC 3979 > > > > > > > > > > Bert > > > > > > > > > > > -----Original Message----- > > > > > > From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com]On > > > > > > Behalf Of Dan Harkins > > > > > > Sent: Saturday, September 03, 2005 13:47 > > > > > > To: troy@twisted.net > > > > > > Cc: capwap@frascone.com > > > > > > Subject: [Capwap] this is not the thread on expanded > discussion on > > > > > > regulatory certification which has now officially ended > > > > > > > > > > > > > > > > > > Troy, > > > > > > > > > > > > There is no IPR claim on SLAPP to remove. > > > > > > > > > > > > Dan. > > > > > > > > > > > > On Sat, 03 Sep 2005 08:28:56 CDT you wrote > > > > > > > Guys, > > > > > > > > > > > > > > I've been watching the argument on this thread and feel > > > > > > that it's time to > > > > > > > make a statement as a working group member. There are two > > > > > > very separate > > > > > > > arguments going on here. One is related to IPR claims and > > > > > > the other around > > > > > > > image download and FCC violations. I am not making this > > > > > > comment around the > > > > > > > image download portion but believe it's essential to > > > > > > discuss the IPR issue. > > > > > > > > > > > > > > I've seen the IPR game getting out of hand within the IETF > > > > > > for way too long. > > > > > > > There are way too many drafts that are coming into the IETF > > > > > > standards > > > > > > > process claiming IPR. > > > > > > > > > > > > > > The purpose for the CAPWAP working group is to create an > > > > > > OPEN standard that > > > > > > > all vendors can implement and show interoperability. > > > > > > Regardless of the > > > > > > > image download argument, before I'll stand up and back the > > > > > > LWAPP or SLAPP > > > > > > > contribution, I want Cisco as well as Trapeze to remove any > > > > > > notion of owing > > > > > > > IPR where they can go after other vendors that implement an > > > > > > IETF standard. > > > > > > > That simply does not wash. > > > > > > > > > > > > > > If the IPR comment stands then we as a working group must > > > > > > engineer around > > > > > > > any/all requirements and come up with a standard that does > > > > > > not allow one > > > > > > > vendor to have that type of power. > > > > > > > > > > > > > > I do not buy into any comments such as "we would never do > > > > > > it" or "we want to > > > > > > > contribute to this moving forward" etc. If that is the > > > > > > case, drop the IPR > > > > > > > claim and then we can go back to considering what protocol > > > > > > would best > > > > > > > represent the basis for CAPWAP. > > > > > > > > > > > > > > The notion of trying to move on from this topic and even > > > > > > consider using a > > > > > > > protocol that has this type of IPR claim is ridiculous > > > > > > (IMHO). I want an > > > > > > > IPR free protocol standard out of this group. > > > > > > > > > > > > > > So there are two questions. Will both the main authors of > > > > > > each of the specs > > > > > > > remove any/all IPR claims for consideration of being in the > > > > > > spec? It's a > > > > > > > simple question of yes or no. Please do not present a long > > > > > > reply without > > > > > > > answering it as a binary decision. > > > > > > > > > > > > > > -Troy > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: capwap-admin@frascone.com > > > > > > [mailto:capwap-admin@frascone.com] On > > > > > > > > Behalf Of Dan Harkins > > > > > > > > Sent: Saturday, September 03, 2005 12:53 AM > > > > > > > > To: Bob O'Hara (boohara) > > > > > > > > Cc: capwap@frascone.com > > > > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > > > > > certification > > > > > > > > > > > > > > > > Bob, > > > > > > > > > > > > > > > > On Fri, 02 Sep 2005 13:15:10 PDT you wrote > > > > > > > > [snip] > > > > > > > > > > > > > > > > > > Both the SLAPP and LWAPP protocol proposals include the > > > > > > ability to > > > > > > > > download c > > > > > > > > >ode to an AP/WTP. The difference between the two is > > > > > > that CAPWAP requires > > > > > > > > an a > > > > > > > > >uthentication signature must be validated before a > > > > > > download can be used, > > > > > > > > while > > > > > > > > > SLAPP has no such mechanism and specifically allows > > > > > > download of code > > > > > > > > from sou > > > > > > > > >rces other than the manufacturer or an authorized > > > > delegate of the > > > > > > > > manufacturer > > > > > > > > >. This is a significant difference between the two > > > > > > protocols and needs > > > > > > > > to be > > > > > > > > >considered when evaluating the protocols during this > > > > > > phase of selecting > > > > > > > > the ba > > > > > > > > >sis for CAPWAP standardization. > > > > > > > > > > > > > > > > "Both the SLAPP and LWAPP protocol proposals.... The > > > > > > difference between > > > > > > > > the > > > > > > > > two is that CAPWAP requires an authentication signature > > > > > > must be validated > > > > > > > > before a download can be used, while SLAPP has no such > > > > > > mechanism...." > > > > > > > > > > > > > > > > LWAPP = CAPWAP? I think you're getting a little excited > > > > > > here Bob. Either > > > > > > > > that or you know something that has not been made public > yet. > > > > > > > > > > > > > > > > What you don't know is how SLAPP works. Please go read > > > > > > the spec. There is > > > > > > > > an authentication step PRIOR to the AC and WTP deciding > > > > > > whether to proceed > > > > > > > > to the full-fledged control and provisioning protocol or > > > > > > to do image > > > > > > > > download. > > > > > > > > > > > > > > > > > Going back to one of my first statements on this topic > > > > > > and to bring this > > > > > > > > arou > > > > > > > > >nd again to why this discussion is important to the > > > > > > working group while > > > > > > > > evalua > > > > > > > > >ting protocols, independent implementations of LWAPP can > > > > > > be built from > > > > > > > > the pro > > > > > > > > >tocol specification, alone. That same statement cannot > > > > > > be made about > > > > > > > > SLAPP. > > > > > > > > > > > > > > > > Wrong! SLAPP includes a complete provisioning and control > > > > > > protocol. > > > > > > > > > > > > > > > > Dan. > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Capwap mailing list > > > > > > > > Capwap@frascone.com > > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Capwap mailing list > > > > > > > Capwap@frascone.com > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 15 08:49:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtAu-0002A9-FR for capwap-archive@megatron.ietf.org; Thu, 15 Sep 2005 08:49:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08228 for ; Thu, 15 Sep 2005 08:49:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50D81202C4; Thu, 15 Sep 2005 08:49:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 147CD1FD6C; Thu, 15 Sep 2005 08:49:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A50C01FD6C for ; Thu, 15 Sep 2005 08:48:12 -0400 (EDT) Received: from gtfw2.enterasys.com (gtfw2.enterasys.com [12.25.1.128]) by mail.frascone.com (Postfix) with ESMTP id 810B31FD63 for ; Thu, 15 Sep 2005 08:48:09 -0400 (EDT) Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j8FCm5ZC006220 for ; Thu, 15 Sep 2005 08:48:05 -0400 (EDT) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 15 Sep 2005 08:48:05 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 15 Sep 2005 08:48:04 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Sep 2005 08:48:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] RE: IPR issues Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901292CB6@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Capwap] RE: IPR issues Thread-Index: AcW4lOLRdDBx2RP1R8CUQd/e/Q0ipQAiH/EgABYoUEAAHwsRBA== From: "Nelson, David" To: X-OriginalArrivalTime: 15 Sep 2005 12:48:00.0195 (UTC) FILETIME=[B43C0130:01C5B9F3] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:51.8443 M:99.4056 P:95.9108 R:95.9108 S:50.7410 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 15 Sep 2005 08:47:59 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Darren Loher writes... > In order to be successful, whatever this working group > creates and emerges as the CAPWAP protocol must be free=20 > of licensing requirements. That may be something of a cat-and-mouse game. As has been observed in = this thread, the WG doesn't know what claims in the unpublished, pending = patents are asserted against the CAPWAP submissions. The fact that IPR = notices have been asserted against all the submissions tends to indicate = that some of the claims are quite broad. As someone who has some experience in structuring the claims in patent = applications, I will observe that it is general practice to include both = narrow as well as broad claims in your application. Generally speaking, = the broader the claims, the more valuable the patent. Some claims may = eventually be disallowed by the Patent and Trademark Office, of course. =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 15 09:08:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtTI-00084X-2j for capwap-archive@megatron.ietf.org; Thu, 15 Sep 2005 09:08:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09174 for ; Thu, 15 Sep 2005 09:08:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 68AF220384; Thu, 15 Sep 2005 09:08:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 695FD1FD6C; Thu, 15 Sep 2005 09:08:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54E991FD6C for ; Thu, 15 Sep 2005 09:07:57 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id 7BBC71FD63 for ; Thu, 15 Sep 2005 09:07:54 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8FD7kXB009270; Thu, 15 Sep 2005 08:07:46 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Sep 2005 15:07:45 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550808E4A5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Nelson, David" , capwap@frascone.com Subject: RE: [Capwap] RE: IPR issues MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 15 Sep 2005 15:07:43 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Inline > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of Nelson, David > Sent: Thursday, September 15, 2005 14:48 > To: capwap@frascone.com > Subject: RE: [Capwap] RE: IPR issues > > > Darren Loher writes... > > > In order to be successful, whatever this working group > > creates and emerges as the CAPWAP protocol must be free > > of licensing requirements. > > That may be something of a cat-and-mouse game. As has been > observed in this thread, the WG doesn't know what claims in > the unpublished, pending patents are asserted against the > CAPWAP submissions. The fact that IPR notices have been > asserted against all the submissions tends to indicate that > some of the claims are quite broad. > Let me also add, that we NEVER know if there are IPR or Patents out there or in the works. There may be people who are not participating in the IETF (and specifically not in this WG) who have IPR or patents in whatever-technology we develop, and they could surface even after we have published a standards track RFC. That is not to say that the WG is not allowed to try and develop a protocol that works around the current IPR claims (however difficult that may turn out to be)... it is to say, that one never knows for sure in advance. Bert > As someone who has some experience in structuring the claims > in patent applications, I will observe that it is general > practice to include both narrow as well as broad claims in > your application. Generally speaking, the broader the > claims, the more valuable the patent. Some claims may > eventually be disallowed by the Patent and Trademark Office, > of course. > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From Smith@outgun.com Thu Sep 15 11:18:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFvVK-0004fX-Fi for capwap-archive@megatron.ietf.org; Thu, 15 Sep 2005 11:18:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17397 for ; Thu, 15 Sep 2005 11:18:23 -0400 (EDT) Received: from 200-153-244-222.dsl.telesp.net.br ([200.153.244.222] helo=online.sh.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFva5-0003uL-S4 for capwap-archive@ietf.org; Thu, 15 Sep 2005 11:23:25 -0400 From: "Lauridsen Peter" To: "Viking Marie" Subject: Re[3]: Date: Thu, 15 Sep 2005 15:18:24 +0000 Message-ID: <499f01c5ba08$05744c9e$54007977@online.sh.cn> X-SA-Do-Not-Rej: Yes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_B53D_40CE1F62.7A89B53D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 2.8 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_B53D_40CE1F62.7A89B53D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cialis Softtabs - when kids aren't home. Go on, give it a try. You'll sure enjoy it! Cialis Softtabs: http://unglazed.net/now/ Discreet, unmarked packaging. >>> NB: No prescription required ------=_NextPart_000_B53D_40CE1F62.7A89B53D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cialis Softtabs - when kids aren't home.
 
Go on, give it a try. = You'll sure=20 enjoy it!
Cialis Softtabs: http://unglazed.net/now/
 
Discreet, unmarked=20 packaging.
 
>>> NB: No = prescription=20 required
------=_NextPart_000_B53D_40CE1F62.7A89B53D-- From capwap-admin@frascone.com Thu Sep 15 13:31:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxZo-0006dl-ON for capwap-archive@megatron.ietf.org; Thu, 15 Sep 2005 13:31:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22709 for ; Thu, 15 Sep 2005 13:31:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8952D2046B; Thu, 15 Sep 2005 13:31:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 88E702043D; Thu, 15 Sep 2005 13:31:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8315B2042D for ; Thu, 15 Sep 2005 13:30:40 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id DD377203E3 for ; Thu, 15 Sep 2005 13:30:37 -0400 (EDT) Message-ID: <148201c5ba1b$2d880760$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Darren Loher" , , References: Subject: Re: [Capwap] RE: IPR issues MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 15 Sep 2005 10:30:33 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think RFC 1822 should be the model. I don't have any problem with a license if it is royalty free, but it will certainly cause problems for the OpenSource community. jak ----- Original Message ----- From: "Darren Loher" To: ; Sent: Wednesday, September 14, 2005 4:31 PM Subject: RE: [Capwap] RE: IPR issues I definitely agree that this is a major problem and poses a major barrier to adoption of a standard. It might help if we knew what was being claimed. This might help us have a discussion about how to deal with the problem. However, since the patent application(s) in question are unpublished it is difficult to do so. The act of requiring a license, even if free, to implement an Internet RFC will pose major problems for some implementers. I respect that Cisco would like to protect themselves from litigation, but this does not sound like a merely protective measure. The latest disclosure specifies that licensing is conditional and is not a free, unconditional license. In order to be successful, whatever this working group creates and emerges as the CAPWAP protocol must be free of licensing requirements. -Darren > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Troy Dixler > Sent: Wednesday, September 14, 2005 5:17 AM > To: capwap@frascone.com > Subject: [Capwap] RE: IPR issues > > Guys, > > I think that we have a major problem with this type of tactic. Clearly the > working group has to move forward with submissions that are free from > Cisco > IPR claims. This type of hijacking of the working group simply cannot be > permitted to take place. The IETF is an open standards working group. Talk > about capitalism taken off the deep end. > > -Troy > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Tuesday, September 13, 2005 1:44 PM > > To: Dan Harkins > > Cc: troy@twisted.net; capwap@frascone.com; dlang@cisco.com > > Subject: RE: IPR issues > > > > Well, you guys were debating potential IPR concerns, and > > so I figured I had to be clear that in accordance with the > > IETF IPR rules and the NOTE WELL statements, anyone who > > know about a patent needs to report on it if they participate. > > > > Best of course is if there are no IPR claims at all, but > > if they do exist, then we (as a WG) better know about > > them early. > > > > Bert > > > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Tuesday, September 13, 2005 18:24 > > > To: Wijnen, Bert (Bert) > > > Cc: troy@twisted.net; capwap@frascone.com; dlang@cisco.com > > > Subject: Re: IPR issues > > > > > > > > > Bert, > > > > > > You overturned a rock and some nastly things crawled out. I > > > refer to: > > > > > > > > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-singh-capwap-ctp.txt > > > > > > So now Cisco is claiming IPR ON ALL SUBMISSIONS TO THIS > > > WORKING GROUP!!! > > > > > > How pathetic. And how utterly baseless. > > > > > > Dan. > > > > > > On Sat, 03 Sep 2005 23:06:28 +0200 you wrote > > > > All, > > > > > > > > I changed the subject line. > > > > This is not about FCC certification but about IPR. > > > > > > > > The question to be asked is: > > > > > > > > does anyone know if there is any IPR anywhere. > > > > > > > > According to the NOTE WELL, if anyone who contributes to > > > > or participates in this WG, then they MUST disclose if they know > > > > about any IPR of the technology being discussed in the WG. > > > > Even if it is IPR that they know someone else is holding. > > > > > > > > And so that includes all submitted technologies. > > > > Pls also read RFC 3978 and RFC 3979 > > > > > > > > Bert > > > > > > > > > -----Original Message----- > > > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com]On > > > > > Behalf Of Dan Harkins > > > > > Sent: Saturday, September 03, 2005 13:47 > > > > > To: troy@twisted.net > > > > > Cc: capwap@frascone.com > > > > > Subject: [Capwap] this is not the thread on expanded discussion on > > > > > regulatory certification which has now officially ended > > > > > > > > > > > > > > > Troy, > > > > > > > > > > There is no IPR claim on SLAPP to remove. > > > > > > > > > > Dan. > > > > > > > > > > On Sat, 03 Sep 2005 08:28:56 CDT you wrote > > > > > > Guys, > > > > > > > > > > > > I've been watching the argument on this thread and feel > > > > > that it's time to > > > > > > make a statement as a working group member. There are two > > > > > very separate > > > > > > arguments going on here. One is related to IPR claims and > > > > > the other around > > > > > > image download and FCC violations. I am not making this > > > > > comment around the > > > > > > image download portion but believe it's essential to > > > > > discuss the IPR issue. > > > > > > > > > > > > I've seen the IPR game getting out of hand within the IETF > > > > > for way too long. > > > > > > There are way too many drafts that are coming into the IETF > > > > > standards > > > > > > process claiming IPR. > > > > > > > > > > > > The purpose for the CAPWAP working group is to create an > > > > > OPEN standard that > > > > > > all vendors can implement and show interoperability. > > > > > Regardless of the > > > > > > image download argument, before I'll stand up and back the > > > > > LWAPP or SLAPP > > > > > > contribution, I want Cisco as well as Trapeze to remove any > > > > > notion of owing > > > > > > IPR where they can go after other vendors that implement an > > > > > IETF standard. > > > > > > That simply does not wash. > > > > > > > > > > > > If the IPR comment stands then we as a working group must > > > > > engineer around > > > > > > any/all requirements and come up with a standard that does > > > > > not allow one > > > > > > vendor to have that type of power. > > > > > > > > > > > > I do not buy into any comments such as "we would never do > > > > > it" or "we want to > > > > > > contribute to this moving forward" etc. If that is the > > > > > case, drop the IPR > > > > > > claim and then we can go back to considering what protocol > > > > > would best > > > > > > represent the basis for CAPWAP. > > > > > > > > > > > > The notion of trying to move on from this topic and even > > > > > consider using a > > > > > > protocol that has this type of IPR claim is ridiculous > > > > > (IMHO). I want an > > > > > > IPR free protocol standard out of this group. > > > > > > > > > > > > So there are two questions. Will both the main authors of > > > > > each of the specs > > > > > > remove any/all IPR claims for consideration of being in the > > > > > spec? It's a > > > > > > simple question of yes or no. Please do not present a long > > > > > reply without > > > > > > answering it as a binary decision. > > > > > > > > > > > > -Troy > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: capwap-admin@frascone.com > > > > > [mailto:capwap-admin@frascone.com] On > > > > > > > Behalf Of Dan Harkins > > > > > > > Sent: Saturday, September 03, 2005 12:53 AM > > > > > > > To: Bob O'Hara (boohara) > > > > > > > Cc: capwap@frascone.com > > > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > > > > certification > > > > > > > > > > > > > > Bob, > > > > > > > > > > > > > > On Fri, 02 Sep 2005 13:15:10 PDT you wrote > > > > > > > [snip] > > > > > > > > > > > > > > > > Both the SLAPP and LWAPP protocol proposals include the > > > > > ability to > > > > > > > download c > > > > > > > >ode to an AP/WTP. The difference between the two is > > > > > that CAPWAP requires > > > > > > > an a > > > > > > > >uthentication signature must be validated before a > > > > > download can be used, > > > > > > > while > > > > > > > > SLAPP has no such mechanism and specifically allows > > > > > download of code > > > > > > > from sou > > > > > > > >rces other than the manufacturer or an authorized > > > delegate of the > > > > > > > manufacturer > > > > > > > >. This is a significant difference between the two > > > > > protocols and needs > > > > > > > to be > > > > > > > >considered when evaluating the protocols during this > > > > > phase of selecting > > > > > > > the ba > > > > > > > >sis for CAPWAP standardization. > > > > > > > > > > > > > > "Both the SLAPP and LWAPP protocol proposals.... The > > > > > difference between > > > > > > > the > > > > > > > two is that CAPWAP requires an authentication signature > > > > > must be validated > > > > > > > before a download can be used, while SLAPP has no such > > > > > mechanism...." > > > > > > > > > > > > > > LWAPP = CAPWAP? I think you're getting a little excited > > > > > here Bob. Either > > > > > > > that or you know something that has not been made public yet. > > > > > > > > > > > > > > What you don't know is how SLAPP works. Please go read > > > > > the spec. There is > > > > > > > an authentication step PRIOR to the AC and WTP deciding > > > > > whether to proceed > > > > > > > to the full-fledged control and provisioning protocol or > > > > > to do image > > > > > > > download. > > > > > > > > > > > > > > > Going back to one of my first statements on this topic > > > > > and to bring this > > > > > > > arou > > > > > > > >nd again to why this discussion is important to the > > > > > working group while > > > > > > > evalua > > > > > > > >ting protocols, independent implementations of LWAPP can > > > > > be built from > > > > > > > the pro > > > > > > > >tocol specification, alone. That same statement cannot > > > > > be made about > > > > > > > SLAPP. > > > > > > > > > > > > > > Wrong! SLAPP includes a complete provisioning and control > > > > > protocol. > > > > > > > > > > > > > > Dan. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Capwap mailing list > > > > > > > Capwap@frascone.com > > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > _______________________________________________ > > > > > > Capwap mailing list > > > > > > Capwap@frascone.com > > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From Codes@enter.vg Thu Sep 15 13:35:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxdp-0007ms-PC for capwap-archive@megatron.ietf.org; Thu, 15 Sep 2005 13:35:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22853 for ; Thu, 15 Sep 2005 13:35:20 -0400 (EDT) Received: from [201.29.197.199] (helo=email.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFxie-0007J1-JM for capwap-archive@ietf.org; Thu, 15 Sep 2005 13:40:22 -0400 From: "Aiken Kyle" To: "Baker Graeme" Subject: Re[2]: Date: Thu, 15 Sep 2005 17:35:22 +0000 Message-ID: <1ad001c5ba1b$0d2fa5d9$54007977@email.com.cn> X-SA-Do-Not-Rej: Yes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_7A89_B53D40CE.1F627A89" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_7A89_B53D40CE.1F627A89 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SPUR-m [Sperm pills] - no time to talk. Go on, give it a try. You'll sure enjoy it! SPUR-m [Cum pills]: http://rehire.net/ Discreet, unmarked packaging. >>> NB: No prescription required ------=_NextPart_000_7A89_B53D40CE.1F627A89 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SPUR-m [Sperm pills] - no time to talk.
 
Go on, give it a try. = You'll sure=20 enjoy it!
SPUR-m [Cum pills]: http://rehire.net/
 
Discreet, unmarked=20 packaging.
 
>>> NB: No = prescription=20 required
------=_NextPart_000_7A89_B53D40CE.1F627A89-- From Lai@freemail.org.mk Thu Sep 15 14:12:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFyDm-0000gR-FC for capwap-archive@megatron.ietf.org; Thu, 15 Sep 2005 14:12:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24789 for ; Thu, 15 Sep 2005 14:12:28 -0400 (EDT) Received: from bhu86.neoplus.adsl.tpnet.pl ([83.28.110.86] helo=forum.dk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFyIZ-0008IO-Fj for capwap-archive@ietf.org; Thu, 15 Sep 2005 14:17:31 -0400 From: "Ostapuk Alexandr" To: "Ostapuk Alexandr" Subject: Re[1]: Date: Thu, 15 Sep 2005 18:12:28 +0000 Message-ID: <453801c5ba21$033d4885$54007977@forum.dk> X-SA-Do-Not-Rej: Yes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1F62_7A89B53D.40CE1F62" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_1F62_7A89B53D.40CE1F62 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MORE-SIZE - when kids aren't home. Go on, give it a try. You'll sure enjoy it! MORE-SIZE: http://efficacies.net/more/ Discreet, unmarked packaging. >>> NB: No prescription required ------=_NextPart_000_1F62_7A89B53D.40CE1F62 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
MORE-SIZE - when kids aren't home.
 
Go on, give it a try. = You'll sure=20 enjoy it!
MORE-SIZE: http://efficacies.net/more/
 
Discreet, unmarked=20 packaging.
 
>>> NB: No = prescription=20 required
------=_NextPart_000_1F62_7A89B53D.40CE1F62-- From capwap-admin@frascone.com Thu Sep 15 14:45:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFyjQ-0001BT-Ta for capwap-archive@megatron.ietf.org; Thu, 15 Sep 2005 14:45:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27278 for ; Thu, 15 Sep 2005 14:45:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D8302046B; Thu, 15 Sep 2005 14:45:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 529571FE1E; Thu, 15 Sep 2005 14:45:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 04A161FE1E for ; Thu, 15 Sep 2005 14:44:11 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id C169E1FE1B for ; Thu, 15 Sep 2005 14:44:08 -0400 (EDT) Message-ID: <152f01c5ba25$7388f940$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Ted Lemon" Cc: "Darren Loher" , , References: <148201c5ba1b$2d880760$196115ac@dcml.docomolabsusa.com> Subject: Re: [Capwap] RE: IPR issues MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 15 Sep 2005 11:44:06 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 8bit Let's be careful to distinguish which IPR notice we're talking about. As I read the two disclosures (and I'm not a lawyer so take this for what it's worth), the license associated with LWAPP would be royalty free if it is adopted as a standard, the claimed terms for the others are RAND, which would not be royality free. Have I got that right? jak ----- Original Message ----- From: "Ted Lemon" To: "James Kempf" Cc: "Darren Loher" ; ; Sent: Thursday, September 15, 2005 11:07 AM Subject: Re: [Capwap] RE: IPR issues On Sep 15, 2005, at 10:30 AM, James Kempf wrote: > I don't have any problem with a license if it is royalty free, but it > will certainly cause problems for the OpenSource community. The license in this case isn't royalty free. It's "reasonable," which can mean anything, although in my experience to date Cisco has in fact been reasonable in the sense of the word that I normally use. The relevant document here is RFC3979, which doesn't explicitly say what to do, but has a good discussion of the issues involved. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 15 21:12:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG4lw-0002iB-AX for capwap-archive@megatron.ietf.org; Thu, 15 Sep 2005 21:12:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21750 for ; Thu, 15 Sep 2005 21:12:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F6DC20261; Thu, 15 Sep 2005 21:12:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A00D11FDE9; Thu, 15 Sep 2005 21:12:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34BE31FDE9 for ; Thu, 15 Sep 2005 21:11:34 -0400 (EDT) Received: from oz.twisted.net (oz.twisted.net [69.211.34.241]) by mail.frascone.com (Postfix) with ESMTP id 778CA1FD6C for ; Thu, 15 Sep 2005 21:11:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by oz.twisted.net (Postfix) with ESMTP id 0C438599C9A; Thu, 15 Sep 2005 20:22:08 -0500 (CDT) Received: from oz.twisted.net ([127.0.0.1]) by localhost (oz.twisted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66919-04; Thu, 15 Sep 2005 20:22:07 -0500 (CDT) Received: from noodle (sindrome.twisted.net [172.16.0.5]) by oz.twisted.net (Postfix) with ESMTP id AD588598ED9; Thu, 15 Sep 2005 20:21:59 -0500 (CDT) Reply-To: From: "Troy Dixler" To: "'Susan Hares'" , "'Dan Harkins'" , "'Wijnen, Bert (Bert)'" Cc: , Subject: RE: [Capwap] Re: IPR issues MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 thread-index: AcW4gJXwNHYKmTOrRUaGrdkq5DpeDgBq5McAAAt4nyA= In-Reply-To: <6F44D7F6B24A8F4DA0AB46C9BE924F02012C17AE@VS4.EXCHPROD.USA.NET> Message-Id: <20050916012159.AD588598ED9@oz.twisted.net> X-Virus-Scanned: by amavisd-new at twisted.net X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 15 Sep 2005 20:09:53 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit It's interesting to see that Sue/Nexthop's language is very different compared to the terms that Cisco is using. The problem of course is all the IPR claims are based on LWAPP as the core protocol. I give Sue credit as she goes out of her way to disclose what is clearly not in the IPR claim yet still doesn't answer the specifics of what is in the claim. Additionally Cisco's IPR claim is over LWAPP as well and it's clear from the language that the undertones are not ones that I feel comfortable with. The SLAPP proposal was very articulate that there are no IPR claims in the proposal. The point around SLAPP having stated there is no IPR claim and the potential issues that LWAPP can bring with Cisco's language - there's a feeling of heartburn that I just can't get over regardless whether people believe LWAPP has technical merits that SLAPP does not have. It's my opinion that we should strongly consider working with the base draft and get the appropriate technical hooks into it and know we are starting with a basis for a "royalty free no IPR" draft and get back to working on OPEN standards. -Troy > -----Original Message----- > From: Susan Hares [mailto:skh@nexthop.com] > Sent: Thursday, September 15, 2005 2:37 PM > To: Dan Harkins; Wijnen, Bert (Bert) > Cc: troy@twisted.net; capwap@frascone.com; dlang@cisco.com > Subject: RE: [Capwap] Re: IPR issues > > Dan and Bert: > > In line with Bert's encouragement to submit any IPR that impacts any > CAPWAP proposal, I would like to pass on to the working group the > existence of another piece of IPR. > > > ====================================================================== > NextHop Technologies is the holder of 1 or more pending patent > applications related to the LWAPP (Light Weight Access Point Protocol) > specified in the Internet draft: draft-ohara-capwap-lwapp-03.txt. > > If technology in this document is included in a standard adopted by IETF > and any claims of any NextHop Technologies patents are necessary for > practicing the standard, any party will have the right to use any such > patent claims under reasonable, non-discriminatory terms to implement > and fully comply with the standard. > > ====================================================================== > > > > > A couple of things I would like to indicate before the questions begin: > > 1) Please note that this IPR is held solely by NextHop Technologies. > > 2) I would like to further indicate that the current byte formats of > LWAPP or SLAPP packets are not listed in this IPR. Included in the > IPR (but not limited to) is a pre-LWAPP CAPWAP protocol. > > I support the efforts of the CAPWAP Evaluation team and this lively > debate. > > > > Sue Hares > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Dan Harkins > Sent: Tuesday, September 13, 2005 12:24 PM > To: Wijnen, Bert (Bert) > Cc: troy@twisted.net; capwap@frascone.com; dlang@cisco.com > Subject: [Capwap] Re: IPR issues > > Bert, > > You overturned a rock and some nastly things crawled out. I refer to: > > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-singh-capwap-ctp.txt > > So now Cisco is claiming IPR ON ALL SUBMISSIONS TO THIS WORKING GROUP!!! > > How pathetic. And how utterly baseless. > > Dan. > > On Sat, 03 Sep 2005 23:06:28 +0200 you wrote > > All, > > > > I changed the subject line. > > This is not about FCC certification but about IPR. > > > > The question to be asked is: > > > > does anyone know if there is any IPR anywhere. > > > > According to the NOTE WELL, if anyone who contributes to > > or participates in this WG, then they MUST disclose if they know > > about any IPR of the technology being discussed in the WG. > > Even if it is IPR that they know someone else is holding. > > > > And so that includes all submitted technologies. > > Pls also read RFC 3978 and RFC 3979 > > > > Bert > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > > Behalf Of Dan Harkins > > > Sent: Saturday, September 03, 2005 13:47 > > > To: troy@twisted.net > > > Cc: capwap@frascone.com > > > Subject: [Capwap] this is not the thread on expanded discussion on > > > regulatory certification which has now officially ended > > > > > > > > > Troy, > > > > > > There is no IPR claim on SLAPP to remove. > > > > > > Dan. > > > > > > On Sat, 03 Sep 2005 08:28:56 CDT you wrote > > > > Guys, > > > > > > > > I've been watching the argument on this thread and feel > > > that it's time to > > > > make a statement as a working group member. There are two > > > very separate > > > > arguments going on here. One is related to IPR claims and > > > the other around > > > > image download and FCC violations. I am not making this > > > comment around the > > > > image download portion but believe it's essential to > > > discuss the IPR issue. > > > > > > > > I've seen the IPR game getting out of hand within the IETF > > > for way too long. > > > > There are way too many drafts that are coming into the IETF > > > standards > > > > process claiming IPR. > > > > > > > > The purpose for the CAPWAP working group is to create an > > > OPEN standard that > > > > all vendors can implement and show interoperability. > > > Regardless of the > > > > image download argument, before I'll stand up and back the > > > LWAPP or SLAPP > > > > contribution, I want Cisco as well as Trapeze to remove any > > > notion of owing > > > > IPR where they can go after other vendors that implement an > > > IETF standard. > > > > That simply does not wash. > > > > > > > > If the IPR comment stands then we as a working group must > > > engineer around > > > > any/all requirements and come up with a standard that does > > > not allow one > > > > vendor to have that type of power. > > > > > > > > I do not buy into any comments such as "we would never do > > > it" or "we want to > > > > contribute to this moving forward" etc. If that is the > > > case, drop the IPR > > > > claim and then we can go back to considering what protocol > > > would best > > > > represent the basis for CAPWAP. > > > > > > > > The notion of trying to move on from this topic and even > > > consider using a > > > > protocol that has this type of IPR claim is ridiculous > > > (IMHO). I want an > > > > IPR free protocol standard out of this group. > > > > > > > > So there are two questions. Will both the main authors of > > > each of the specs > > > > remove any/all IPR claims for consideration of being in the > > > spec? It's a > > > > simple question of yes or no. Please do not present a long > > > reply without > > > > answering it as a binary decision. > > > > > > > > -Troy > > > > > > > > > > > > > -----Original Message----- > > > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On > > > > > Behalf Of Dan Harkins > > > > > Sent: Saturday, September 03, 2005 12:53 AM > > > > > To: Bob O'Hara (boohara) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Expanded discussion on regulatory > > > certification > > > > > > > > > > Bob, > > > > > > > > > > On Fri, 02 Sep 2005 13:15:10 PDT you wrote > > > > > [snip] > > > > > > > > > > > > Both the SLAPP and LWAPP protocol proposals include the > > > ability to > > > > > download c > > > > > >ode to an AP/WTP. The difference between the two is > > > that CAPWAP requires > > > > > an a > > > > > >uthentication signature must be validated before a > > > download can be used, > > > > > while > > > > > > SLAPP has no such mechanism and specifically allows > > > download of code > > > > > from sou > > > > > >rces other than the manufacturer or an authorized delegate of > the > > > > > manufacturer > > > > > >. This is a significant difference between the two > > > protocols and needs > > > > > to be > > > > > >considered when evaluating the protocols during this > > > phase of selecting > > > > > the ba > > > > > >sis for CAPWAP standardization. > > > > > > > > > > "Both the SLAPP and LWAPP protocol proposals.... The > > > difference between > > > > > the > > > > > two is that CAPWAP requires an authentication signature > > > must be validated > > > > > before a download can be used, while SLAPP has no such > > > mechanism...." > > > > > > > > > > LWAPP = CAPWAP? I think you're getting a little excited > > > here Bob. Either > > > > > that or you know something that has not been made public yet. > > > > > > > > > > What you don't know is how SLAPP works. Please go read > > > the spec. There is > > > > > an authentication step PRIOR to the AC and WTP deciding > > > whether to proceed > > > > > to the full-fledged control and provisioning protocol or > > > to do image > > > > > download. > > > > > > > > > > > Going back to one of my first statements on this topic > > > and to bring this > > > > > arou > > > > > >nd again to why this discussion is important to the > > > working group while > > > > > evalua > > > > > >ting protocols, independent implementations of LWAPP can > > > be built from > > > > > the pro > > > > > >tocol specification, alone. That same statement cannot > > > be made about > > > > > SLAPP. > > > > > > > > > > Wrong! SLAPP includes a complete provisioning and control > > > protocol. > > > > > > > > > > Dan. > > > > > > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 16 00:58:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG8Id-0007Yb-Ne for capwap-archive@megatron.ietf.org; Fri, 16 Sep 2005 00:58:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10465 for ; Fri, 16 Sep 2005 00:58:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27A96202E3; Fri, 16 Sep 2005 00:58:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 609561FE1E; Fri, 16 Sep 2005 00:58:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 23CF51FE1E for ; Fri, 16 Sep 2005 00:57:55 -0400 (EDT) Received: from huawei-3com.com (smtp.huawei-3com.com [210.21.230.51]) by mail.frascone.com (Postfix) with ESMTP id 92B311FDE9 for ; Fri, 16 Sep 2005 00:57:53 -0400 (EDT) Received: from smtp.huawei-3com.com (localhost [127.0.0.1]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0IMW00GNX8CKSQ@smtp.huawei-3com.com> for capwap@frascone.com; Fri, 16 Sep 2005 12:55:33 +0800 (CST) Received: from huawei-3com.com (ldapb.huawei-3com.com [172.19.1.228]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0IMW00GT58CKE0@smtp.huawei-3com.com> for capwap@frascone.com; Fri, 16 Sep 2005 12:55:32 +0800 (CST) Received: from [10.18.1.7] by mail.huawei-3com.com (mshttpd); Fri, 16 Sep 2005 09:56:31 +0500 From: zhaoyujin 00919 Subject: =?gb2312?B?u9i4tA==?=:RE: RE: [Capwap] Re: In-band/out-of-band about the firmware download To: "Pat Calhoun [pacalhou@cisco.com]" Cc: capwap@frascone.com Message-id: <1ed501ec56.1ec561ed50@huawei-3com.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) 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 AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 16 Sep 2005 09:56:31 +0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I think if we have known the problem=2C we maybe give a solution for the = problem=2E Only for example we can define mechanism which type is equal to 0x0000000= 1 is common download mechanism (In-band download mechanism)=2E If an AP c= an support the in-band download=2C the AC may choose the in-band download= for the AP=2E Best regards Michael =3E But once more this introduces optional download mechanisms=2C which = =3E means interoperability issues=2E =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 00919 =5Bzhaoyujin=40huawei-3com=2Ecom=5D = =3E =3E Sent=3A Wednesday=2C September 14=2C 2005 2=3A46 AM =3E =3E To=3A Pat Calhoun (pacalhou) =3E =3E Cc=3A capwap=40frascone=2Ecom =3E =3E Subject=3A =BB=D8=B8=B4=3ARE=3A =5BCapwap=5D Re=3A In-band/out-of= -band about the = =3E =3E firmware download =3E =3E = =3E =3E I think capwap wants to define a control management of AP=2E = =3E =3E And I think the WG has give some firmware download mechinasm = =3E =3E which is enough for the capwap=2E =3E =3E = =3E =3E But the firmware download is only a small part of the control = =3E =3E management=2E And at present there are many file transimission = =3E =3E protocol=2C capwap may think about using those protocol=2E =3E =3E = =3E =3E If the vendor has not support any file transimission = =3E =3E protocol=2C it can use the in-band firmware download=2E Otherwise= = =3E =3E the vendor may choose to negotiate which type download mechinasm=2E= =3E =3E = =3E =3E = =3E =3E = =3E =3E =3E Vendors should always be free to make changes to protocols=2C= = =3E =3E as long as = =3E =3E =3E the protocol allows for vendor extensions=2E That said=2C the= = =3E =3E WG needs to = =3E =3E =3E define a mandatory to implement mode - and if that is the = =3E case=2C I = =3E =3E =3E wonderwhy a vendor would feel compelled to support multiple = =3E =3E methods=2E = =3E =3E =3E If the concern is that the mechanism defined by the WG is = =3E =3E =3E insufficient=2C then they should try to address that problem = =3E =3E in the WG=2E =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 capwap-admin=40frascone=2Ecom =3E =3E =3E =3E =5Bcapwap-admin=40frascone=2Ecom=5D On Behalf Of zhaoyuji= n 00919 =3E =3E =3E =3E Sent=3A Monday=2C September 12=2C 2005 9=3A24 PM =3E =3E =3E =3E To=3A capwap-admin=40frascone=2Ecom =3E =3E =3E =3E Cc=3A capwap=40frascone=2Ecom =3E =3E =3E =3E Subject=3A =5BCapwap=5D Re=3A In-band/out-of-band about t= he firmware =3E =3E =3E download=3E = =3E =3E =3E =3E CAPWAP defines an architecture of WLAN=2E At present ther= e are = =3E may = =3E =3E =3E =3E realization protocols--LWAPP=2CSLAPP=2CCTP=2C and so on=2E= =3E =3E =3E =3E = =3E =3E =3E =3E All those protocols use control tunnel and data tunnel=2E= = =3E =3E In one mail = =3E =3E =3E =3E the next information is mentionned=3A=22in-band = =3E mechanism(Download = =3E =3E =3E =3E firmware with control tunnel)=22 and =22out-of-band = =3E =3E mechanism(Download = =3E =3E =3E =3E firmware with other protocol like ftp=2Ctftp)=22=2E And t= he mail = =3E give = =3E =3E =3E =3E another mention--=22perhaps a slightly more compicated = =3E =3E state machine=2E=22 =3E =3E =3E =3E = =3E =3E =3E =3E But in fact the out-of-band mechanism is not very = =3E compicated=2E = =3E =3E =3E =3E If the capwap uses the out-of-band mechanism=2C the = =3E =3E function will be = =3E =3E =3E =3E clarified=2E =3E =3E =3E =3E = =3E =3E =3E =3E Can we add a payload in the version negotiation packet=2E= = =3E =3E This payload = =3E =3E =3E =3E can decide the firmware download mechanism=2E For example= the = =3E =3E =3E =3E mechanism can use OUI+type=2E If the OUI is equal to = =3E =3E 0x000000=2C capwap = =3E =3E =3E =3E should think the download mechanism is common=2E Otherwis= e the = =3E =3E =3E =3E mechanise is private for vendor=2E =3E =3E =3E =3E = =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 =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 =3E =3E =3E =3E Capwap mailing list =3E =3E =3E =3E Capwap=40frascone=2Ecom =3E =3E =3E =3E http=3A//mail=2Efrascone=2Ecom/mailman/listinfo/capwap =3E =3E =3E =3E = =3E =3E =3E =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 =3E =3E =3E Capwap mailing list =3E =3E =3E Capwap=40frascone=2Ecom =3E =3E =3E http=3A//mail=2Efrascone=2Ecom/mailman/listinfo/capwap =3E =3E =3E = =3E =3E = =3E =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 =3E Capwap mailing list =3E Capwap=40frascone=2Ecom =3E http=3A//mail=2Efrascone=2Ecom/mailman/listinfo/capwap =3E _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 16 02:02:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG9Id-0005Cy-Va for capwap-archive@megatron.ietf.org; Fri, 16 Sep 2005 02:02:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14637 for ; Fri, 16 Sep 2005 02:02:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DB5520383; Fri, 16 Sep 2005 02:02:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D6A5620263; Fri, 16 Sep 2005 02:02:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B334120263 for ; Fri, 16 Sep 2005 02:01:13 -0400 (EDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by mail.frascone.com (Postfix) with ESMTP id DB6C31FE1E for ; Fri, 16 Sep 2005 02:01:11 -0400 (EDT) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 005144F0011 for ; Fri, 16 Sep 2005 08:01:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 08:00:26 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 08:00:26 +0200 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 Message-ID: Thread-Topic: How to handle sequence numbers with LWAPP Thread-Index: AcW6g+7N2ZBfRYR8SUGRYAhbQNE9sw== From: "Peter Nilsson J (LI/EAB)" To: X-OriginalArrivalTime: 16 Sep 2005 06:00:26.0543 (UTC) FILETIME=[EF2293F0:01C5BA83] X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] How to handle sequence numbers with LWAPP Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 16 Sep 2005 08:00:26 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, When the AC perform a 802.11i Group Key Handshake it is supposed to = provide the Key RSC (last transmit sequence number) to the supplicant in = message 1. But since the sequence counter is maintained in the MAC in the WTP I = wonder how this is supposed to work? Regards Peter Nilsson Ericsson _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 16 02:12:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG9SJ-0007Y2-JA for capwap-archive@megatron.ietf.org; Fri, 16 Sep 2005 02:12:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24466 for ; Fri, 16 Sep 2005 02:12:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 468941FE1E; Fri, 16 Sep 2005 02:12:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E27E20270; Fri, 16 Sep 2005 02:12:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE1EC20270 for ; Fri, 16 Sep 2005 02:11:59 -0400 (EDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by mail.frascone.com (Postfix) with ESMTP id 813671FE1E for ; Fri, 16 Sep 2005 02:11:56 -0400 (EDT) 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 j8G6BqEQ028059; Fri, 16 Sep 2005 15:11:52 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j8G6BqI29004; Fri, 16 Sep 2005 15:11:52 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id j8G6Bqs13598; Fri, 16 Sep 2005 15:11:52 +0900 (JST) 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] How to handle sequence numbers with LWAPP Message-ID: <5F09D220B62F79418461A978CA0921BD5EF22D@pslexc01.psl.local> Thread-topic: [Capwap] How to handle sequence numbers with LWAPP Thread-Index: AcW6g+7N2ZBfRYR8SUGRYAhbQNE9swAAC/IQ From: "Saravanan Govindan" To: "Peter Nilsson J (LI/EAB)" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 16 Sep 2005 14:09:27 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Peter, I think this is a good case you point out. It is covered by the IEEE 802.11i Considerations objective.=20 I am not sure of LWAPP but in WiCoP, a Key Config message is used to transport the group key handshake message from AC to the WTP. The KeyRSC fields are left unassigned by the AC. Then after receiving the Key Config message, the WTP assings the Key RSC field with the prevailing counter value. The handshake message is then sent to the terminal.=20 Cheers, Saravanan > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Peter Nilsson=20 > J (LI/EAB) > Sent: Friday, September 16, 2005 2:00 PM > To: capwap@frascone.com > Subject: [Capwap] How to handle sequence numbers with LWAPP >=20 > Hi, >=20 > When the AC perform a 802.11i Group Key Handshake it is=20 > supposed to provide the Key RSC (last transmit sequence=20 > number) to the supplicant in message 1. > But since the sequence counter is maintained in the MAC in=20 > the WTP I wonder how this is supposed to work? >=20 > Regards > Peter Nilsson > Ericsson > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 16 03:51:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGB04-00059P-AM for capwap-archive@megatron.ietf.org; Fri, 16 Sep 2005 03:51:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00450 for ; Fri, 16 Sep 2005 03:51:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1EF772043D; Fri, 16 Sep 2005 03:51:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F143720270; Fri, 16 Sep 2005 03:51:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 708B420270 for ; Fri, 16 Sep 2005 03:50:56 -0400 (EDT) Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mail.frascone.com (Postfix) with ESMTP id 9EC371FE1E for ; Fri, 16 Sep 2005 03:50:53 -0400 (EDT) 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 <0IMW00D0RGRD2M@szxga01-in.huawei.com> for capwap@frascone.com; Fri, 16 Sep 2005 15:57:13 +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 <0IMW00DAPGRAPM@szxga01-in.huawei.com> for capwap@frascone.com; Fri, 16 Sep 2005 15:57:13 +0800 (CST) Received: from dell60 ([10.18.4.207]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IMW00C1DGZ5HO@szxml01-in.huawei.com>; Fri, 16 Sep 2005 16:01:55 +0800 (CST) From: sujay In-reply-to: <1ed501ec56.1ec561ed50@huawei-3com.com> To: "'zhaoyujin 00919'" , "'Pat Calhoun [pacalhou@cisco.com]'" Cc: capwap@frascone.com Message-id: <001901c5ba93$7c447ff0$cf04120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] =?utf-8?Q?RE:_=C2=BB=C3=98=C2=B8=C2=B4:RE:_RE:_=5BCapwap=5D_Re:_In-band/ou?= =?utf-8?Q?t-of-band__about_the_firmware_download?= Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 16 Sep 2005 13:21:44 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Even if the negotiation capability is added about the download = mechanism, For multi-vendor AP interoperability, the AC should support both In-band and Out-band mechanism. Else opt for a single protocol confirmity and either In-band or Out-band = mechanism ! ~Sujay -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of zhaoyujin 00919 Sent: Friday, September 16, 2005 10:27 AM To: Pat Calhoun [pacalhou@cisco.com] Cc: capwap@frascone.com Subject: =E5=9B=9E=E5=A4=8D:RE: RE: [Capwap] Re: In-band/out-of-band = about the firmware download I think if we have known the problem, we maybe give a solution for the = problem. Only for example we can define mechanism which type is equal to = 0x00000001 is common download mechanism (In-band download mechanism). If = an AP can support the in-band download, the AC may choose the in-band = download for the AP. Best regards Michael > But once more this introduces optional download mechanisms, which > means interoperability issues. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 >=20 >=20 > > -----Original Message----- > > From: zhaoyujin 00919 [zhaoyujin@huawei-3com.com] > > Sent: Wednesday, September 14, 2005 2:46 AM > > To: Pat Calhoun (pacalhou) > > Cc: capwap@frascone.com > > Subject: =E5=9B=9E=E5=A4=8D:RE: [Capwap] Re: In-band/out-of-band = about the=20 > > firmware download > >=20 > > I think capwap wants to define a control management of AP. > > And I think the WG has give some firmware download mechinasm=20 > > which is enough for the capwap. > >=20 > > But the firmware download is only a small part of the control > > management. And at present there are many file transimission=20 > > protocol, capwap may think about using those protocol. > >=20 > > If the vendor has not support any file transimission > > protocol, it can use the in-band firmware download. Otherwise=20 > > the vendor may choose to negotiate which type download mechinasm. > >=20 > >=20 > >=20 > > > Vendors should always be free to make changes to protocols, > > as long as > > > the protocol allows for vendor extensions. That said, the > > WG needs to > > > define a mandatory to implement mode - and if that is the > case, I > > > wonderwhy a vendor would feel compelled to support multiple > > methods. > > > If the concern is that the mechanism defined by the WG is > > > insufficient, then they should try to address that problem=20 > > in the WG. > > >=20 > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com [capwap-admin@frascone.com] On=20 > > > > Behalf Of zhaoyujin 00919 > > > > Sent: Monday, September 12, 2005 9:24 PM > > > > To: capwap-admin@frascone.com > > > > Cc: capwap@frascone.com > > > > Subject: [Capwap] Re: In-band/out-of-band about the firmware > > > download>=20 > > > > CAPWAP defines an architecture of WLAN. At present there are > may > > > > realization protocols--LWAPP,SLAPP,CTP, and so on. > > > >=20 > > > > All those protocols use control tunnel and data tunnel. > > In one mail > > > > the next information is mentionned:"in-band > mechanism(Download > > > > firmware with control tunnel)" and "out-of-band > > mechanism(Download > > > > firmware with other protocol like ftp,tftp)". And the mail > give > > > > another mention--"perhaps a slightly more compicated > > state machine." > > > >=20 > > > > But in fact the out-of-band mechanism is not very > compicated. > > > > If the capwap uses the out-of-band mechanism, the > > function will be > > > > clarified. > > > >=20 > > > > Can we add a payload in the version negotiation packet. > > This payload > > > > can decide the firmware download mechanism. For example the > > > > mechanism can use OUI+type. If the OUI is equal to=20 > > 0x000000, capwap > > > > should think the download mechanism is common. Otherwise the > > > > mechanise is private for vendor. > > > >=20 > > > >=20 > > > > Best regards > > > > Michael > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com=20 > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > >=20 > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com=20 > > > http://mail.frascone.com/mailman/listinfo/capwap > > >=20 > >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Sep 16 06:51:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGDoG-0008Ec-K4 for capwap-archive@megatron.ietf.org; Fri, 16 Sep 2005 06:51:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08374 for ; Fri, 16 Sep 2005 06:51:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D4EC20383; Fri, 16 Sep 2005 06:51:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BA0320270; Fri, 16 Sep 2005 06:51:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1BD2920270 for ; Fri, 16 Sep 2005 06:50:14 -0400 (EDT) Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mail.frascone.com (Postfix) with ESMTP id 47A0A1FE1E for ; Fri, 16 Sep 2005 06:50:11 -0400 (EDT) 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 <0IMW00872P27KT@szxga01-in.huawei.com> for capwap@frascone.com; Fri, 16 Sep 2005 18:56:31 +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 <0IMW00DLHP27PJ@szxga01-in.huawei.com> for capwap@frascone.com; Fri, 16 Sep 2005 18:56:31 +0800 (CST) Received: from RAMANATHANS ([10.18.4.56]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IMW00CKRPA2WE@szxml01-in.huawei.com> for capwap@frascone.com; Fri, 16 Sep 2005 19:01:15 +0800 (CST) From: ramanathans To: capwap@frascone.com Reply-To: ramanathans@huawei.com Message-id: <000001c5baac$89b3cb50$3804120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: multipart/alternative; boundary="Boundary_(ID_8owjxIYdD0r3yL7Ypj1xvg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Doubt Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 16 Sep 2005 16:21:04 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --Boundary_(ID_8owjxIYdD0r3yL7Ypj1xvg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi all, I am very new to this LWAPP. When I was reading the STATE DIAGRAM I did not understand when the state transition is from JOIN -------> IDLE and JOIN -----------> DISCOVERY For both of them they gave the same reason for transition. Can anybody explain why? Bye --Boundary_(ID_8owjxIYdD0r3yL7Ypj1xvg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi all,

            I am very new to this LWAPP. When I was reading the STATE DIAGRAM

I did not understand when the state transition is from

 

JOIN  -----à  IDLE             and    JOIN  ---------à DISCOVERY

 

 

For  both of them they gave the same  reason for transition. Can anybody explain why?

 

 

 

Bye

 

 

--Boundary_(ID_8owjxIYdD0r3yL7Ypj1xvg)-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Sep 18 21:50:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHAnN-0001av-1u for capwap-archive@megatron.ietf.org; Sun, 18 Sep 2005 21:50:17 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08208 for ; Sun, 18 Sep 2005 21:50:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2B0D20531; Sun, 18 Sep 2005 21:50:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4205B2051A; Sun, 18 Sep 2005 21:50:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F5412051A for ; Sun, 18 Sep 2005 21:49:48 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 3070E204DA for ; Sun, 18 Sep 2005 21:49:45 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 18 Sep 2005 18:49:45 -0700 X-IronPort-AV: i="3.97,120,1125903600"; d="scan'208"; a="342866425:sNHT33355064" 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 j8J1nTKK015863; Sun, 18 Sep 2005 18:49:39 -0700 (PDT) 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, 18 Sep 2005 18:49:38 -0700 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] RE: IPR issues Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2AD554B@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] RE: IPR issues Thread-Index: AcW6JdWUTRNr/JJqQ06va3o4japV9ACi2Tgg From: "Pat Calhoun [pacalhou@cisco.com]" To: "James Kempf" , "Ted Lemon" Cc: "Darren Loher" , , X-OriginalArrivalTime: 19 Sep 2005 01:49:38.0543 (UTC) FILETIME=[65113FF0:01C5BCBC] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sun, 18 Sep 2005 18:47:57 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable That is correct, James. LWAPP is royalty free, while the others (SLAPP, CTP, WiCOP) are under RAND terms. Folks, while I understand the concerns raised on the list, I would like to remind everyone that many technologies developed by IETF (any any SDO for that matter) have IPR claims around them. Nonetheless, if these technologies address a market need, they end up being very successful. Further, there is no guarantee that additional IPR claims won't show up at a later date. There are many wireless companies that have no representation in this working group, and given the protocol independence objective of CAPWAP, I wouldn't be surprised if additional IPR is identified at a later date. But just because IPR exists does not make a technology less successful. In fact, I would point you to https://datatracker.ietf.org/public/ipr_list.cgi for a snapshot of the current IPR claims for all of the IETF work in progress. Many IETF protocols are widely deployed that have IPR claims against them, and these are very successful. In fact, if one were to design a WLAN system, chances are one would run into other IPR claims that exist out of IEEE, such as Trapeze's claims on 802.11e, 802.11f, 802.11k and 802.11i (the last one being a clear example that patents do not stop a protocol's usefulness), and the CAPWAP protocol is just part of the overall WLAN system. As we evaluate specific protocols, they each have their pros and cons. In the end, a protocol must be chosen based on its completeness, its ability to solve the problem, etc. IPR is just one of many criterion that we must deal with during the protocol engineering process. Trying to avoid known patents today does not guarantee a patent free protocol by any means, nor does enhancing a lesser protocol.=20 So I would urge the WG to look at IPR as one of many issues that must be dealt with in our engineering task ahead of us... Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > Sent: Thursday, September 15, 2005 11:44 AM > To: Ted Lemon > Cc: Darren Loher; troy@twisted.net; capwap@frascone.com > Subject: Re: [Capwap] RE: IPR issues >=20 > Let's be careful to distinguish which IPR notice we're=20 > talking about. As I read the two disclosures (and I'm not a=20 > lawyer so take this for what it's worth), the license=20 > associated with LWAPP would be royalty free if it is adopted=20 > as a standard, the claimed terms for the others are RAND,=20 > which would not be royality free. >=20 > Have I got that right? >=20 > jak >=20 > ----- Original Message ----- > From: "Ted Lemon" > To: "James Kempf" > Cc: "Darren Loher" ;=20 > ; > Sent: Thursday, September 15, 2005 11:07 AM > Subject: Re: [Capwap] RE: IPR issues >=20 >=20 > =12On Sep 15, 2005, at 10:30 AM, James Kempf wrote: > > I don't have any problem with a license if it is royalty=20 > free, but it=20 > > will certainly cause problems for the OpenSource community. >=20 > The license in this case isn't royalty free. It's "reasonable," > which can mean anything, although in my experience to date=20 > Cisco has in fact been reasonable in the sense of the word=20 > that I normally > use. The relevant document here is RFC3979, which doesn't > explicitly say what to do, but has a good discussion of the=20 > issues involved. >=20 >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 19 04:54:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHHPf-0005FM-S1 for capwap-archive@megatron.ietf.org; Mon, 19 Sep 2005 04:54:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06745 for ; Mon, 19 Sep 2005 04:54:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C13121FDE9; Mon, 19 Sep 2005 04:54:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 752E61FC5F; Mon, 19 Sep 2005 04:54:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C08DA1FC5F for ; Mon, 19 Sep 2005 04:53:22 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id E02F61FC24 for ; Mon, 19 Sep 2005 04:53:20 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8J8rDFs029983; Mon, 19 Sep 2005 03:53:14 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 19 Sep 2005 10:53:12 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550815A869@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Pat Calhoun [pacalhou@cisco.com]" , James Kempf , Ted Lemon Cc: Darren Loher , troy@twisted.net, capwap@frascone.com Subject: RE: [Capwap] RE: IPR issues MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Sep 2005 10:53:10 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I do not want to get too deep into the WG deliberations as to what they want to do w.r.t the IPR claims. But... First, I would like to remind EVERYONE who participates (that is if you are subscribed to the mailing list, of which we have records) and who knows about IPR, that you MUST disclose such information according to IETF participation rules. See the NOTE WELL that you all MUST have received. I can post it here again if people want me to. Sooner is better than later. We better have ALL the IPR claims and disclosures on the table when we (as a WG) talk about this. Inline.. > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of Pat Calhoun [pacalhou@cisco.com] > Sent: Monday, September 19, 2005 03:48 > To: James Kempf; Ted Lemon > Cc: Darren Loher; troy@twisted.net; capwap@frascone.com > Subject: RE: [Capwap] RE: IPR issues > > > That is correct, James. LWAPP is royalty free, while the others (SLAPP, > CTP, WiCOP) are under RAND terms. > Maybe I do not understand the above sentence well enough. I though that we as a WG want to develop a CAPWAP protocol. It could be that we use one or multiple of the above to pick and choose from (or use one as a base and merge pieces from the others). So I would think that whatever IPR there is on some specific technology or method, that it could or could not apply to the CAPWAP protocol (that still needs to be defined/specified). We (as a WG) wonder what impacts any IPR might have on the to-be-developed CAPWAP protocol. We do not really care too much what the terms and conditions are of any IPR on LWAPP or SLAPP or CTP or WiCOP. Because I doubt we will end up with an unmodified spec of one of these, and for sure we will call it CAPWAP and not any of the current names (or so is/was my perception of the discussions sofar). So Pat, what does your above sentence mean in the context of our ultimate CAPWAP protocol? > Folks, while I understand the concerns raised on the list, I would like > to remind everyone that many technologies developed by IETF (any any SDO > for that matter) have IPR claims around them. Nonetheless, if these > technologies address a market need, they end up being very successful. > Such is true. And it is up to THIS WG to decide what they want to do. One option is to live with whatever IPR claims there are. Another option is to try and define a protocol that is not impacted by the (known) IPR claims or disclosures. Will probably take longer, but that is what it is. > Further, there is no guarantee that additional IPR claims won't show up > at a later date. There are many wireless companies that have no > representation in this working group, and given the protocol > independence objective of CAPWAP, I wouldn't be surprised if additional > IPR is identified at a later date. > Such is true too, but PLEASE everyone look at the NOTE WELL. You MUST disclose if you know about IPR for the technology that we are trying to develop a protocol for. ... snip .. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > Bert Wijnen _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 20 13:54:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmJv-0002Ab-MY for capwap-archive@megatron.ietf.org; Tue, 20 Sep 2005 13:54:27 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19280 for ; Tue, 20 Sep 2005 13:54:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B748202AF; Tue, 20 Sep 2005 13:54:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A8EA20278; Tue, 20 Sep 2005 13:54:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C490220278 for ; Tue, 20 Sep 2005 13:53:39 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 86C6B20230 for ; Tue, 20 Sep 2005 13:53:36 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 10:57:24 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 10:53:01 -0700 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 Message-ID: Thread-Topic: IPR issues Thread-Index: AcW895ZrTISm0gKITBSavMwCn/xSLABAIzcA From: "Darren Loher" To: "Wijnen, Bert (Bert)" , "Pat Calhoun [pacalhou@cisco.com]" , "James Kempf" , "Ted Lemon" Cc: , X-OriginalArrivalTime: 20 Sep 2005 17:53:01.0507 (UTC) FILETIME=[24BB5930:01C5BE0C] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: IPR issues Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 20 Sep 2005 10:52:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I definitely agree with Bert that this working group is creating a CAPWAP protocol. I also believe the CAPWAP protocol should be based on one of the current proposals and incorporate important capabilities which are found among all the proposals. The final, standards track protocol which emerges from this working group should be called the CAPWAP protocol. =20 Whether or not Cisco will have IPR claims on the final CAPWAP protocol depends largely on exactly what the technical claims are. I believe Cisco needs to reveal what these claims are so the working group can take them into consideration. In my opinion, the ideal CAPWAP protocol would not have any licensing requirements, free or otherwise. If there are licensing requirements, then the license holder may control who may implement the protocol by virtue of not granting a license. =20 -Darren=20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, September 19, 2005 2:53 AM > To: Pat Calhoun [pacalhou@cisco.com]; James Kempf; Ted Lemon > Cc: Darren Loher; troy@twisted.net; capwap@frascone.com > Subject: RE: [Capwap] RE: IPR issues >=20 > I do not want to get too deep into the WG deliberations as to what they > want to do w.r.t the IPR claims. But... >=20 > > First, I would like to remind EVERYONE who participates (that is if you > are subscribed to the mailing list, of which we have records) and who > knows > about IPR, that you MUST disclose such information according to IETF > participation rules. See the NOTE WELL that you all MUST have received. > I can post it here again if people want me to. > >=20 > Sooner is better than later. We better have ALL the IPR claims and > disclosures > on the table when we (as a WG) talk about this. >=20 > Inline.. >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of Pat Calhoun [pacalhou@cisco.com] > > Sent: Monday, September 19, 2005 03:48 > > To: James Kempf; Ted Lemon > > Cc: Darren Loher; troy@twisted.net; capwap@frascone.com > > Subject: RE: [Capwap] RE: IPR issues > > > > > > That is correct, James. LWAPP is royalty free, while the others (SLAPP, > > CTP, WiCOP) are under RAND terms. > > >=20 > Maybe I do not understand the above sentence well enough. > I though that we as a WG want to develop a CAPWAP protocol. > It could be that we use one or multiple of the above to pick and choose > from (or use one as a base and merge pieces from the others). So I would > think that whatever IPR there is on some specific technology or method, > that it could or could not apply to the CAPWAP protocol (that still needs > to be defined/specified). We (as a WG) wonder what impacts any IPR > might have on the to-be-developed CAPWAP protocol. >=20 > We do not really care too much what the terms and conditions are of any > IPR on LWAPP or SLAPP or CTP or WiCOP. Because I doubt we will end up with > an unmodified spec of one of these, and for sure we will call it CAPWAP > and not any of the current names (or so is/was my perception of the > discussions sofar). >=20 > So Pat, what does your above sentence mean in the context of our > ultimate CAPWAP protocol? >=20 >=20 > > Folks, while I understand the concerns raised on the list, I would like > > to remind everyone that many technologies developed by IETF (any any SDO > > for that matter) have IPR claims around them. Nonetheless, if these > > technologies address a market need, they end up being very successful. > > >=20 > Such is true. And it is up to THIS WG to decide what they want to do. > One option is to live with whatever IPR claims there are. > Another option is to try and define a protocol that is not impacted > by the (known) IPR claims or disclosures. Will probably take longer, > but that is what it is. >=20 > > Further, there is no guarantee that additional IPR claims won't show up > > at a later date. There are many wireless companies that have no > > representation in this working group, and given the protocol > > independence objective of CAPWAP, I wouldn't be surprised if additional > > IPR is identified at a later date. > > > Such is true too, but PLEASE everyone look at the NOTE WELL. > You MUST disclose if you know about IPR for the technology that we are > trying to develop a protocol for. >=20 > ... snip .. >=20 > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > >=20 > Bert Wijnen _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 20 14:29:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmrf-0003A8-Eu for capwap-archive@megatron.ietf.org; Tue, 20 Sep 2005 14:29:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21025 for ; Tue, 20 Sep 2005 14:29:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F9FF202AF; Tue, 20 Sep 2005 14:29:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 694F120278; Tue, 20 Sep 2005 14:29:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1B5B20278 for ; Tue, 20 Sep 2005 14:28:16 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 6DF6720230 for ; Tue, 20 Sep 2005 14:28:13 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j8KILkQc008627; Tue, 20 Sep 2005 11:21:46 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509201821.j8KILkQc008627@homebrew.trpz.com> To: "Pat Calhoun [pacalhou@cisco.com]" Cc: "James Kempf" , "Ted Lemon" , "Darren Loher" , troy@twisted.net, capwap@frascone.com Subject: Re: [Capwap] RE: IPR issues In-Reply-To: Your message of "Sun, 18 Sep 2005 18:47:57 PDT." <4FF84B0BC277FF45AA27FE969DD956A2AD554B@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8625.1127240506.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 20 Sep 2005 11:21:46 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Pat, Your statement that "LWAPP is royalty free" has a huge condition applied to it. It is only "royalty free" for a company if it does not assert its own IPR against Cisco, on anything and not just its own claims on LWAPP. As I stated earlier, that means that Cisco is free to steal one piece of intellectual property from each company that implements LWAPP. Royalty free would be something like this: http://www.ietf.org/ietf/IPR/CAST-128-entrust LWAPP is _NOT ROYALTY FREE_. Dan. On Sun, 18 Sep 2005 18:47:57 PDT you wrote > That is correct, James. LWAPP is royalty free, while the others (SLAPP, > CTP, WiCOP) are under RAND terms. > > Folks, while I understand the concerns raised on the list, I would like > to remind everyone that many technologies developed by IETF (any any SDO > for that matter) have IPR claims around them. Nonetheless, if these > technologies address a market need, they end up being very successful. > > Further, there is no guarantee that additional IPR claims won't show up > at a later date. There are many wireless companies that have no > representation in this working group, and given the protocol > independence objective of CAPWAP, I wouldn't be surprised if additional > IPR is identified at a later date. > > But just because IPR exists does not make a technology less successful. > In fact, I would point you to > https://datatracker.ietf.org/public/ipr_list.cgi for a snapshot of the > current IPR claims for all of the IETF work in progress. Many IETF > protocols are widely deployed that have IPR claims against them, and > these are very successful. In fact, if one were to design a WLAN system, > chances are one would run into other IPR claims that exist out of IEEE, > such as Trapeze's claims on 802.11e, 802.11f, 802.11k and 802.11i (the > last one being a clear example that patents do not stop a protocol's > usefulness), and the CAPWAP protocol is just part of the overall WLAN > system. > > As we evaluate specific protocols, they each have their pros and cons. > In the end, a protocol must be chosen based on its completeness, its > ability to solve the problem, etc. IPR is just one of many criterion > that we must deal with during the protocol engineering process. Trying > to avoid known patents today does not guarantee a patent free protocol > by any means, nor does enhancing a lesser protocol. > > So I would urge the WG to look at IPR as one of many issues that must be > dealt with in our engineering task ahead of us... > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > Sent: Thursday, September 15, 2005 11:44 AM > > To: Ted Lemon > > Cc: Darren Loher; troy@twisted.net; capwap@frascone.com > > Subject: Re: [Capwap] RE: IPR issues > > > > Let's be careful to distinguish which IPR notice we're > > talking about. As I read the two disclosures (and I'm not a > > lawyer so take this for what it's worth), the license > > associated with LWAPP would be royalty free if it is adopted > > as a standard, the claimed terms for the others are RAND, > > which would not be royality free. > > > > Have I got that right? > > > > jak > > > > ----- Original Message ----- > > From: "Ted Lemon" > > To: "James Kempf" > > Cc: "Darren Loher" ; > > ; > > Sent: Thursday, September 15, 2005 11:07 AM > > Subject: Re: [Capwap] RE: IPR issues > > > > > > On Sep 15, 2005, at 10:30 AM, James Kempf wrote: > > > I don't have any problem with a license if it is royalty > free, but it > > > will certainly cause problems for the OpenSource community. > > > > The license in this case isn't royalty free. It's "reasonable," > > which can mean anything, although in my experience to date > > Cisco has in fact been reasonable in the sense of the word > > that I normally > > use. The relevant document here is RFC3979, which doesn't > > explicitly say what to do, but has a good discussion of the > > issues involved. > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 20 16:46:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHp0G-00080f-Gi for capwap-archive@megatron.ietf.org; Tue, 20 Sep 2005 16:46:17 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04688 for ; Tue, 20 Sep 2005 16:46:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BDD9D202BA; Tue, 20 Sep 2005 16:46:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B97691FE1B; Tue, 20 Sep 2005 16:46:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C59161FE1B for ; Tue, 20 Sep 2005 16:45:14 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 8483D1FE0E for ; Tue, 20 Sep 2005 16:45:11 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j8KKcWIM009064; Tue, 20 Sep 2005 13:38:37 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509202038.j8KKcWIM009064@homebrew.trpz.com> To: "Susan Hares" Cc: "Pat Calhoun [pacalhou@cisco.com]" , "James Kempf" , "Ted Lemon" , "Darren Loher" , troy@twisted.net, capwap@frascone.com Subject: Re: [Capwap] RE: IPR issues In-Reply-To: Your message of "Tue, 20 Sep 2005 13:11:33 MDT." <6F44D7F6B24A8F4DA0AB46C9BE924F02013F6337@VS4.EXCHPROD.USA.NET> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9062.1127248712.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 20 Sep 2005 13:38:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sue, I have received more than one off-the-list question about what I meant by "free to steal". Since I meant what I said and do not think it's pejorative let me clarify. Imagine the Foobar company has some patented technology to do software fast switching (or rogue detection, or station location or ...) and they also implemented LWAPP in their wireless switch because it was the standard. Cisco can implement that patented techology without a license and if the Foobar company asserts a claim against Cisco then Cisco will revoke the free license for Foobar to implement LWAPP. The licensing terms for LWAPP would be at least as bad-- or "good" if you don't want me to be pejorative-- as Foobar's terms to implement their software fast switching technology (I know this because Cisco is run by very good businessmen and they have a fiduciary responsibility to their shareholders). Either that or there would be a cross-licensing deal. So now Cisco gets to use this technology for free. (Repeat sequence indefinitely for different companies and different patented technologies). Because of this Cisco could (I'm not saying they are or will or have in the past, just that the terms they are asserting give them the ability to) implement a technology that another company has patented and not license it from the company. They could do this in the knowledge that the sequence of events above would play out if that company asserted a claim against Cisco. That sounds like stealing to me. Not that they did do this or are doing this but they are free to do it if they want to. Since Pat has said that they are asserting exactly what I claim they're asserting (no "I'm not a lawyer" disclaimer needed) this I don't think I'm being pejorative. If Cisco would never do such a thing then they should change their disclosure to specificly disallow it. Regardless though, LWAPP is _not royalty free_. Dan. On Tue, 20 Sep 2005 13:11:33 MDT you wrote > Dan, Pat, Troy and Bert: > > Bert seems to want a very specific disclosure of IPR regarding the > CAPWAP proposals. This disclosure goes beyond the packet formats for > inter-operability to algorithms behind the packet exchange. Bert's > request seems to be broad - any Network management ever impacting > CAPWAP. IMHO (and I'm not a lawyer) this was not the intent of the IPR > policy from the IETF. > > I have sent a request to Bert, David Kessens, Mani and Dorothy a private > memo asking for clarification on the exact request that Bert/David > Kessens or Mani and Dorothy would like to see. I will respond to a > precise request for additional details to the best of my abilities. > > If specific details of extend of IPR details, I would like this to be > done in an environment that encourages clarity without pejorative > comments. Again - I request that ADs, or chairs or the Evaluation > committee gather this information in a through manner. > > I hope you-all will join me in this method of discussing IPR related to > CAPWAP. > > Sue Hares > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Dan Harkins > Sent: Tuesday, September 20, 2005 2:22 PM > To: Pat Calhoun [pacalhou@cisco.com] > Cc: James Kempf; Ted Lemon; Darren Loher; troy@twisted.net; > capwap@frascone.com > Subject: Re: [Capwap] RE: IPR issues > > Pat, > > Your statement that "LWAPP is royalty free" has a huge condition > applied to it. It is only "royalty free" for a company if it does not > assert its own IPR against Cisco, on anything and not just its own > claims on LWAPP. > > As I stated earlier, that means that Cisco is free to steal one piece > of intellectual property from each company that implements LWAPP. > > Royalty free would be something like this: > > http://www.ietf.org/ietf/IPR/CAST-128-entrust > > LWAPP is _NOT ROYALTY FREE_. > > Dan. > > On Sun, 18 Sep 2005 18:47:57 PDT you wrote > > That is correct, James. LWAPP is royalty free, while the others > (SLAPP, > > CTP, WiCOP) are under RAND terms. > > > > Folks, while I understand the concerns raised on the list, I would > like > > to remind everyone that many technologies developed by IETF (any any > SDO > > for that matter) have IPR claims around them. Nonetheless, if these > > technologies address a market need, they end up being very successful. > > > > Further, there is no guarantee that additional IPR claims won't show > up > > at a later date. There are many wireless companies that have no > > representation in this working group, and given the protocol > > independence objective of CAPWAP, I wouldn't be surprised if > additional > > IPR is identified at a later date. > > > > But just because IPR exists does not make a technology less > successful. > > In fact, I would point you to > > https://datatracker.ietf.org/public/ipr_list.cgi for a snapshot of the > > current IPR claims for all of the IETF work in progress. Many IETF > > protocols are widely deployed that have IPR claims against them, and > > these are very successful. In fact, if one were to design a WLAN > system, > > chances are one would run into other IPR claims that exist out of > IEEE, > > such as Trapeze's claims on 802.11e, 802.11f, 802.11k and 802.11i (the > > last one being a clear example that patents do not stop a protocol's > > usefulness), and the CAPWAP protocol is just part of the overall WLAN > > system. > > > > As we evaluate specific protocols, they each have their pros and cons. > > In the end, a protocol must be chosen based on its completeness, its > > ability to solve the problem, etc. IPR is just one of many criterion > > that we must deal with during the protocol engineering process. > Trying > > to avoid known patents today does not guarantee a patent free protocol > > by any means, nor does enhancing a lesser protocol. > > > > So I would urge the WG to look at IPR as one of many issues that must > be > > dealt with in our engineering task ahead of us... > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > > Sent: Thursday, September 15, 2005 11:44 AM > > > To: Ted Lemon > > > Cc: Darren Loher; troy@twisted.net; capwap@frascone.com > > > Subject: Re: [Capwap] RE: IPR issues > > > > > > Let's be careful to distinguish which IPR notice we're > > > talking about. As I read the two disclosures (and I'm not a > > > lawyer so take this for what it's worth), the license > > > associated with LWAPP would be royalty free if it is adopted > > > as a standard, the claimed terms for the others are RAND, > > > which would not be royality free. > > > > > > Have I got that right? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Ted Lemon" > > > To: "James Kempf" > > > Cc: "Darren Loher" ; > > > ; > > > Sent: Thursday, September 15, 2005 11:07 AM > > > Subject: Re: [Capwap] RE: IPR issues > > > > > > > > > On Sep 15, 2005, at 10:30 AM, James Kempf wrote: > > > > I don't have any problem with a license if it is royalty > > free, but it > > > > will certainly cause problems for the OpenSource community. > > > > > > The license in this case isn't royalty free. It's "reasonable," > > > which can mean anything, although in my experience to date > > > Cisco has in fact been reasonable in the sense of the word > > > that I normally > > > use. The relevant document here is RFC3979, which doesn't > > > explicitly say what to do, but has a good discussion of the > > > issues involved. > > > > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 20 18:12:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqLV-0000LQ-Ig for capwap-archive@megatron.ietf.org; Tue, 20 Sep 2005 18:12:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09545 for ; Tue, 20 Sep 2005 18:12:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67E56203E9; Tue, 20 Sep 2005 18:12:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E5C620371; Tue, 20 Sep 2005 18:12:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3202520371 for ; Tue, 20 Sep 2005 18:11:44 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 2F669202C6 for ; Tue, 20 Sep 2005 18:11:40 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8KM8rma006901 for ; Tue, 20 Sep 2005 18:08:54 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8KM8Lma006141 for ; Tue, 20 Sep 2005 18:08:30 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BE30.3131B382" Message-ID: Thread-Topic: A note on IPR issues Thread-Index: AcW+L9x3x9BcN5iuQRqa9+Nopv1UjQ== From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] A note on IPR issues Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 20 Sep 2005 16:11:04 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5BE30.3131B382 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The AD has pointed out the need to and usefulness of disclosing all IPR that there may be or known to be existing out there. =20 In addition - the chairs would urge the disclosures to be as detailed as can be in order to facilitate the WG to decide its course of action among the many options this may lead to in terms of adoption of a protocol that the WG can come to a consensus on - an acceptable base protocol and work further to get to an interoperable CAPWAP protocol. =20 An example of a clear (detailed) one is the ID#144 that points to related enough information for WG to review and form an opinion. =20 So - whether it is being expansive in scope - it will be indeed useful to the WG which has appeared to approach getting to a CAPWAP protocol based on work done so far in the WG & evaluation exercise and WG's review of it. =20 -mani ------_=_NextPart_001_01C5BE30.3131B382 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The AD has pointed out the need to and usefulness of = disclosing all IPR that there may be or known to be existing out = there.

 

In addition – the chairs would urge the = disclosures to be as detailed as can be in order to facilitate the WG to decide its = course of action among the

many options this may lead to in terms of adoption of = a protocol that the WG can come to a consensus on – an acceptable = base protocol and work further

to get to an interoperable CAPWAP = protocol.

 

An example of a clear (detailed) one is the ID#144 = that points to related enough information for WG to review and form an = opinion.

 

So – whether it is being expansive in scope = – it will be indeed useful to the WG which has appeared to approach getting = to a CAPWAP protocol based on

work done so far in the WG & evaluation exercise = and WG’s review of it.

 

-mani

------_=_NextPart_001_01C5BE30.3131B382-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 20 19:35:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHrdo-0007UF-Qr for capwap-archive@megatron.ietf.org; Tue, 20 Sep 2005 19:35:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14794 for ; Tue, 20 Sep 2005 19:35:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E458F20433; Tue, 20 Sep 2005 19:35:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50360203E9; Tue, 20 Sep 2005 19:35:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 98AAE203E9 for ; Tue, 20 Sep 2005 19:34:22 -0400 (EDT) Received: from aruba-mx.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by mail.frascone.com (Postfix) with SMTP id 66E8E20388 for ; Tue, 20 Sep 2005 19:34:19 -0400 (EDT) Received: from lotus.arubanetworks.com ([10.3.9.203]) by aruba-mx.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Sep 2005 16:34:18 -0700 From: Partha Narasimhan X-X-Sender: pn@lotus.arubanetworks.com To: "Pat Calhoun [pacalhou@cisco.com]" Cc: James Kempf , Ted Lemon , Darren Loher , troy@twisted.net, capwap@frascone.com Subject: RE: [Capwap] RE: IPR issues In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2AD554B@xmb-sjc-235.amer.cisco.com> Message-ID: References: <4FF84B0BC277FF45AA27FE969DD956A2AD554B@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 20 Sep 2005 23:34:18.0747 (UTC) FILETIME=[D21E34B0:01C5BE3B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 20 Sep 2005 16:34:18 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Sun, 18 Sep 2005, Pat Calhoun [pacalhou@cisco.com] wrote: > Further, there is no guarantee that additional IPR claims won't show up > at a later date. There are many wireless companies that have no > representation in this working group, and given the protocol > independence objective of CAPWAP, I wouldn't be surprised if additional > IPR is identified at a later date. While this is a risk that we all have to live with, the situation here is worse because the recent IPR claims have come from an active participant in the WG. Including the fact that the presence of such claims has been revealed so late in the game without any details of these claims. In line with other opinions expressed on the mailing list, it is important that those with specific claims come forward with the details of such claims so that the WG may be able to determine the appropriate course of action to move forward. IMHO, these recent IPR claims have created a dark cloud over the activities of this WG and the removal of which is required for further progress. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 20 19:48:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHrqN-0002i0-GZ for capwap-archive@megatron.ietf.org; Tue, 20 Sep 2005 19:48:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15219 for ; Tue, 20 Sep 2005 19:48:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8728D2043E; Tue, 20 Sep 2005 19:48:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 060EF2041A; Tue, 20 Sep 2005 19:48:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4A9A02041A for ; Tue, 20 Sep 2005 19:47:14 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 1485E20388 for ; Tue, 20 Sep 2005 19:47:11 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2005 16:47:11 -0700 X-IronPort-AV: i="3.97,128,1125903600"; d="scan'208"; a="343737704:sNHT34768290" 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 j8KNku54018213; Tue, 20 Sep 2005 16:47:05 -0700 (PDT) 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, 20 Sep 2005 16:47:00 -0700 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] RE: IPR issues Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2AD5F97@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] RE: IPR issues Thread-Index: AcW+ERZFlB+wDuUOS7uTp5RvDeimTgAEl9eg From: "Pat Calhoun [pacalhou@cisco.com]" To: "Dan Harkins" Cc: "James Kempf" , "Ted Lemon" , "Darren Loher" , , , X-OriginalArrivalTime: 20 Sep 2005 23:47:00.0040 (UTC) FILETIME=[97E24C80:01C5BE3D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 20 Sep 2005 16:46:58 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dan, Given you keep bringing up this point, could I possibly ask how you differentiate the LWAPP IPR licensing language from Trapeze's IPR statement on 802.11e, 802.11f, 802.11k and 802.11i, which I quote: "... said royalty-free license shall terminate should the licensee assert any intellectual property claims against Trapeze Networks". Just to be clear, your firm has used the exact same language in at least four scenarios that I am aware of, so clearly the LWAPP statement is really not that unusual - is it? So once more, you can cook up a plethora of imaginary scenarios where my firm attempts to limit others from participating in this space, but the reality is this does not represent past, or current, behavior. Once more, I point you to https://datatracker.ietf.org/public/ipr_list.cgi which includes a variety of examples where Cisco (not to mention other firms) have IPR claims against successful technologies, and ironically enough, the presence of IPR has not stopped companies from innovating, or being successful. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > Sent: Tuesday, September 20, 2005 11:22 AM > To: Pat Calhoun [pacalhou@cisco.com] > Cc: James Kempf; Ted Lemon; Darren Loher; troy@twisted.net;=20 > capwap@frascone.com > Subject: Re: [Capwap] RE: IPR issues=20 >=20 > Pat, >=20 > Your statement that "LWAPP is royalty free" has a huge=20 > condition applied to it. It is only "royalty free" for a=20 > company if it does not assert its own IPR against Cisco, on=20 > anything and not just its own claims on LWAPP.=20 >=20 > As I stated earlier, that means that Cisco is free to steal=20 > one piece of intellectual property from each company that=20 > implements LWAPP.=20 >=20 > Royalty free would be something like this: >=20 > http://www.ietf.org/ietf/IPR/CAST-128-entrust >=20 > LWAPP is _NOT ROYALTY FREE_.=20 >=20 > Dan. >=20 > On Sun, 18 Sep 2005 18:47:57 PDT you wrote > > That is correct, James. LWAPP is royalty free, while the others=20 > > (SLAPP, CTP, WiCOP) are under RAND terms. > >=20 > > Folks, while I understand the concerns raised on the list, I would=20 > > like to remind everyone that many technologies developed by=20 > IETF (any=20 > > any SDO for that matter) have IPR claims around them.=20 > Nonetheless, if=20 > > these technologies address a market need, they end up being=20 > very successful. > >=20 > > Further, there is no guarantee that additional IPR claims=20 > won't show=20 > > up at a later date. There are many wireless companies that have no=20 > > representation in this working group, and given the protocol=20 > > independence objective of CAPWAP, I wouldn't be surprised if=20 > > additional IPR is identified at a later date. > >=20 > > But just because IPR exists does not make a technology less=20 > successful. > > In fact, I would point you to > > https://datatracker.ietf.org/public/ipr_list.cgi for a=20 > snapshot of the=20 > > current IPR claims for all of the IETF work in progress. Many IETF=20 > > protocols are widely deployed that have IPR claims against=20 > them, and=20 > > these are very successful. In fact, if one were to design a WLAN=20 > > system, chances are one would run into other IPR claims=20 > that exist out=20 > > of IEEE, such as Trapeze's claims on 802.11e, 802.11f, 802.11k and=20 > > 802.11i (the last one being a clear example that patents do=20 > not stop a=20 > > protocol's usefulness), and the CAPWAP protocol is just part of the=20 > > overall WLAN system. > >=20 > > As we evaluate specific protocols, they each have their=20 > pros and cons. > > In the end, a protocol must be chosen based on its=20 > completeness, its=20 > > ability to solve the problem, etc. IPR is just one of many=20 > criterion=20 > > that we must deal with during the protocol engineering process. =20 > > Trying to avoid known patents today does not guarantee a=20 > patent free=20 > > protocol by any means, nor does enhancing a lesser protocol. > >=20 > > So I would urge the WG to look at IPR as one of many issues=20 > that must=20 > > be dealt with in our engineering task ahead of us... > >=20 > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > > Sent: Thursday, September 15, 2005 11:44 AM > > > To: Ted Lemon > > > Cc: Darren Loher; troy@twisted.net; capwap@frascone.com > > > Subject: Re: [Capwap] RE: IPR issues > > >=20 > > > Let's be careful to distinguish which IPR notice we're talking=20 > > > about. As I read the two disclosures (and I'm not a=20 > lawyer so take=20 > > > this for what it's worth), the license associated with=20 > LWAPP would=20 > > > be royalty free if it is adopted as a standard, the claimed terms=20 > > > for the others are RAND, which would not be royality free. > > >=20 > > > Have I got that right? > > >=20 > > > jak > > >=20 > > > ----- Original Message ----- > > > From: "Ted Lemon" > > > To: "James Kempf" > > > Cc: "Darren Loher" ; ;=20 > > > > > > Sent: Thursday, September 15, 2005 11:07 AM > > > Subject: Re: [Capwap] RE: IPR issues > > >=20 > > >=20 > > > =12On Sep 15, 2005, at 10:30 AM, James Kempf wrote: > > > > I don't have any problem with a license if it is royalty > > free, but it > > > > will certainly cause problems for the OpenSource community. > > >=20 > > > The license in this case isn't royalty free. It's "reasonable," > > > which can mean anything, although in my experience to=20 > date Cisco has=20 > > > in fact been reasonable in the sense of the word that I normally > > > use. The relevant document here is RFC3979, which doesn't > > > explicitly say what to do, but has a good discussion of=20 > the issues=20 > > > involved. > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > >=20 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 20 20:00:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHs20-0005F8-Ux for capwap-archive@megatron.ietf.org; Tue, 20 Sep 2005 20:00:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15657 for ; Tue, 20 Sep 2005 20:00:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 889112043E; Tue, 20 Sep 2005 20:00:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 82E882041A; Tue, 20 Sep 2005 20:00:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 101B12041A for ; Tue, 20 Sep 2005 19:59:29 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 9A8ED20388 for ; Tue, 20 Sep 2005 19:59:27 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 20 Sep 2005 16:59:26 -0700 X-IronPort-AV: i="3.97,128,1125903600"; d="scan'208"; a="660929386:sNHT36187128" 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 j8KNxL4X022992; Tue, 20 Sep 2005 16:59:23 -0700 (PDT) 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, 20 Sep 2005 16:59:18 -0700 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] RE: IPR issues Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2AD5FAA@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] RE: IPR issues Thread-Index: AcW+JD06H9JTTqXSTtqPaR0sb0eIuwAGquIw From: "Pat Calhoun [pacalhou@cisco.com]" To: "Dan Harkins" , "Susan Hares" Cc: "James Kempf" , "Ted Lemon" , "Darren Loher" , , X-OriginalArrivalTime: 20 Sep 2005 23:59:18.0863 (UTC) FILETIME=[5041BDF0:01C5BE3F] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 20 Sep 2005 16:59:17 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable So, Dan, pray tell, how would this theft scenario outlined be any different from the situation faced by an implementer of the 802.11e, 802.11f, 802.11k and 802.11i standards with regards to Trapeze IP - especially since these need to be implemented in order to build the WLAN system that uses CAPWAP? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > Sent: Tuesday, September 20, 2005 1:39 PM > To: Susan Hares > Cc: Pat Calhoun [pacalhou@cisco.com]; James Kempf; Ted Lemon;=20 > Darren Loher; troy@twisted.net; capwap@frascone.com > Subject: Re: [Capwap] RE: IPR issues=20 >=20 > Sue, >=20 > I have received more than one off-the-list question about=20 > what I meant by "free to steal". Since I meant what I said=20 > and do not think it's pejorative let me clarify. >=20 > Imagine the Foobar company has some patented technology to=20 > do software fast switching (or rogue detection, or station=20 > location or ...) and they also implemented LWAPP in their=20 > wireless switch because it was the standard. Cisco can=20 > implement that patented techology without a license and if=20 > the Foobar company asserts a claim against Cisco then Cisco=20 > will revoke the free license for Foobar to implement LWAPP.=20 > The licensing terms for LWAPP would be at least as bad-- or=20 > "good" if you don't want me to be pejorative-- as Foobar's=20 > terms to implement their software fast switching technology=20 > (I know this because Cisco is run by very good businessmen=20 > and they have a fiduciary responsibility to their=20 > shareholders). Either that or there would be a=20 > cross-licensing deal. So now Cisco gets to use this=20 > technology for free. (Repeat sequence indefinitely for=20 > different companies and different patented technologies). >=20 > Because of this Cisco could (I'm not saying they are or=20 > will or have in the past, just that the terms they are=20 > asserting give them the ability to) implement a technology=20 > that another company has patented and not license it from the=20 > company. They could do this in the knowledge that the=20 > sequence of events above would play out if that company=20 > asserted a claim against Cisco. That sounds like stealing to=20 > me. Not that they did do this or are doing this but they are=20 > free to do it if they want to. >=20 > Since Pat has said that they are asserting exactly what I=20 > claim they're asserting (no "I'm not a lawyer" disclaimer=20 > needed) this I don't think I'm being pejorative. If Cisco=20 > would never do such a thing then they should change their=20 > disclosure to specificly disallow it. >=20 > Regardless though, LWAPP is _not royalty free_. >=20 > Dan. >=20 > On Tue, 20 Sep 2005 13:11:33 MDT you wrote > > Dan, Pat, Troy and Bert: > >=20 > > Bert seems to want a very specific disclosure of IPR regarding the=20 > > CAPWAP proposals. This disclosure goes beyond the packet=20 > formats for=20 > > inter-operability to algorithms behind the packet exchange. Bert's=20 > > request seems to be broad - any Network management ever impacting=20 > > CAPWAP. IMHO (and I'm not a lawyer) this was not the intent of the=20 > > IPR policy from the IETF. > >=20 > > I have sent a request to Bert, David Kessens, Mani and Dorothy a=20 > > private memo asking for clarification on the exact request that=20 > > Bert/David Kessens or Mani and Dorothy would like to see. I will=20 > > respond to a precise request for additional details to the=20 > best of my abilities. > >=20 > > If specific details of extend of IPR details, I would like=20 > this to be=20 > > done in an environment that encourages clarity without pejorative=20 > > comments. Again - I request that ADs, or chairs or the Evaluation=20 > > committee gather this information in a through manner. > >=20 > > I hope you-all will join me in this method of discussing=20 > IPR related=20 > > to CAPWAP. > >=20 > > Sue Hares >=20 > >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > > Behalf Of Dan Harkins > > Sent: Tuesday, September 20, 2005 2:22 PM > > To: Pat Calhoun [pacalhou@cisco.com] > > Cc: James Kempf; Ted Lemon; Darren Loher; troy@twisted.net;=20 > > capwap@frascone.com > > Subject: Re: [Capwap] RE: IPR issues > >=20 > > Pat, > >=20 > > Your statement that "LWAPP is royalty free" has a huge condition=20 > > applied to it. It is only "royalty free" for a company if=20 > it does not=20 > > assert its own IPR against Cisco, on anything and not just its own=20 > > claims on LWAPP. > >=20 > > As I stated earlier, that means that Cisco is free to steal one=20 > > piece of intellectual property from each company that=20 > implements LWAPP. > >=20 > > Royalty free would be something like this: > >=20 > > http://www.ietf.org/ietf/IPR/CAST-128-entrust > >=20 > > LWAPP is _NOT ROYALTY FREE_.=20 > >=20 > > Dan. > >=20 > > On Sun, 18 Sep 2005 18:47:57 PDT you wrote > > > That is correct, James. LWAPP is royalty free, while the others > > (SLAPP, > > > CTP, WiCOP) are under RAND terms. > > >=20 > > > Folks, while I understand the concerns raised on the list, I would > > like > > > to remind everyone that many technologies developed by=20 > IETF (any any > > SDO > > > for that matter) have IPR claims around them.=20 > Nonetheless, if these=20 > > > technologies address a market need, they end up being=20 > very successful. > > >=20 > > > Further, there is no guarantee that additional IPR claims=20 > won't show > > up > > > at a later date. There are many wireless companies that have no=20 > > > representation in this working group, and given the protocol=20 > > > independence objective of CAPWAP, I wouldn't be surprised if > > additional > > > IPR is identified at a later date. > > >=20 > > > But just because IPR exists does not make a technology less > > successful. > > > In fact, I would point you to > > > https://datatracker.ietf.org/public/ipr_list.cgi for a=20 > snapshot of=20 > > > the current IPR claims for all of the IETF work in progress. Many=20 > > > IETF protocols are widely deployed that have IPR claims against=20 > > > them, and these are very successful. In fact, if one were=20 > to design=20 > > > a WLAN > > system, > > > chances are one would run into other IPR claims that exist out of > > IEEE, > > > such as Trapeze's claims on 802.11e, 802.11f, 802.11k and 802.11i=20 > > > (the last one being a clear example that patents do not stop a=20 > > > protocol's usefulness), and the CAPWAP protocol is just=20 > part of the=20 > > > overall WLAN system. > > >=20 > > > As we evaluate specific protocols, they each have their=20 > pros and cons. > > > In the end, a protocol must be chosen based on its=20 > completeness, its=20 > > > ability to solve the problem, etc. IPR is just one of=20 > many criterion=20 > > > that we must deal with during the protocol engineering process. > > Trying > > > to avoid known patents today does not guarantee a patent free=20 > > > protocol by any means, nor does enhancing a lesser protocol. > > >=20 > > > So I would urge the WG to look at IPR as one of many issues that=20 > > > must > > be > > > dealt with in our engineering task ahead of us... > > >=20 > > >=20 > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > > > Sent: Thursday, September 15, 2005 11:44 AM > > > > To: Ted Lemon > > > > Cc: Darren Loher; troy@twisted.net; capwap@frascone.com > > > > Subject: Re: [Capwap] RE: IPR issues > > > >=20 > > > > Let's be careful to distinguish which IPR notice we're talking=20 > > > > about. As I read the two disclosures (and I'm not a=20 > lawyer so take=20 > > > > this for what it's worth), the license associated with=20 > LWAPP would=20 > > > > be royalty free if it is adopted as a standard, the=20 > claimed terms=20 > > > > for the others are RAND, which would not be royality free. > > > >=20 > > > > Have I got that right? > > > >=20 > > > > jak > > > >=20 > > > > ----- Original Message ----- > > > > From: "Ted Lemon" > > > > To: "James Kempf" > > > > Cc: "Darren Loher" ;=20 > ;=20 > > > > > > > > Sent: Thursday, September 15, 2005 11:07 AM > > > > Subject: Re: [Capwap] RE: IPR issues > > > >=20 > > > >=20 > > > > =12On Sep 15, 2005, at 10:30 AM, James Kempf wrote: > > > > > I don't have any problem with a license if it is royalty > > > free, but it > > > > > will certainly cause problems for the OpenSource community. > > > >=20 > > > > The license in this case isn't royalty free. It's=20 > "reasonable," > > > > which can mean anything, although in my experience to=20 > date Cisco=20 > > > > has in fact been reasonable in the sense of the word that I=20 > > > > normally > > > > use. The relevant document here is RFC3979, which doesn't > > > > explicitly say what to do, but has a good discussion of=20 > the issues=20 > > > > involved. > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > >=20 > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > >=20 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > >=20 > >=20 > >=20 > >=20 > >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 20 21:57:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHtrH-0003mu-4h for capwap-archive@megatron.ietf.org; Tue, 20 Sep 2005 21:57:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19964 for ; Tue, 20 Sep 2005 21:57:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BA2E20433; Tue, 20 Sep 2005 21:57:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A43FE20396; Tue, 20 Sep 2005 21:57:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCA3B20396 for ; Tue, 20 Sep 2005 21:56:49 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 535B52026F for ; Tue, 20 Sep 2005 21:56:46 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j8L1oClx010755; Tue, 20 Sep 2005 18:50:12 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509210150.j8L1oClx010755@homebrew.trpz.com> To: "Pat Calhoun [pacalhou@cisco.com]" Cc: "James Kempf" , "Ted Lemon" , "Darren Loher" , troy@twisted.net, capwap@frascone.com, dlang@cisco.com Subject: Re: [Capwap] RE: IPR issues In-Reply-To: Your message of "Tue, 20 Sep 2005 16:46:58 PDT." <4FF84B0BC277FF45AA27FE969DD956A2AD5F97@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10753.1127267412.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 20 Sep 2005 18:50:12 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Pat, I can't. I was not aware that language was added to Trapeze's IEEE letters of assurance. To be fair that is an alternate licensing strategy, the previous paragraph states that Trapeze Networks will offer a non-exclusive license on "reasonable and non-discriminatory terms" provided similar terms are given to Trapeze Networks (which is what I understood the letters to state). But also, to be fair, there is language in there that is, for all intents-and-purposes, exactly the same as LWAPP's IPR licensing language. Needless to say, I am surprised and upset. Are Airespace's/Cisco's claims in 11e, 11i, 11k, 11n, 11r any different? I'd wager that that language was added because that's the same terms other companies were offering their IEEE-related IPR for. Lawyers tend to meet at bottom, and if other IEEE letters of assurance had that language then that's probably the reason it was added to our's. That is not a rhetorical question by the way. Please tell me what the terms are of Airespace's/Cisco's claims for the 5 areas of 802.11 technology that any implementation of CAPWAP would need to also implement. Also, my imaginary scenarios are not attempts by your firm (or apparently my firm!) to limit participation. It is that it invites patent poaching (is that less pejorative?) since cross licensing is the logical result of _ANY_ assertion of IPR. Yes, IPR claims against successful technologies have not hindered that technology. IPR claims against technologies have also not been enforced. I refer to a Cisco employee standing up in the VRRP BOF saying that Cisco's HSRP patents precluded any unencumbered implementation of VRRP and that Cisco would assert those patents against anyone who implemented VRRP. To my knowledge Cisco has not asserted those patents against anyone who implemented VRRP. But, as with purchases of stock, past performance does not guarantee future performance. Dan. On Tue, 20 Sep 2005 16:46:58 PDT you wrote > Dan, > > Given you keep bringing up this point, could I possibly ask how you > differentiate the LWAPP IPR licensing language from Trapeze's IPR > statement on 802.11e, 802.11f, 802.11k and 802.11i, which I quote: > > "... said royalty-free license shall terminate should the licensee > assert any intellectual property claims against Trapeze Networks". > > Just to be clear, your firm has used the exact same language in at least > four scenarios that I am aware of, so clearly the LWAPP statement is > really not that unusual - is it? > > So once more, you can cook up a plethora of imaginary scenarios where my > firm attempts to limit others from participating in this space, but the > reality is this does not represent past, or current, behavior. Once > more, I point you to https://datatracker.ietf.org/public/ipr_list.cgi > which includes a variety of examples where Cisco (not to mention other > firms) have IPR claims against successful technologies, and ironically > enough, the presence of IPR has not stopped companies from innovating, > or being successful. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@trpz.com] > > Sent: Tuesday, September 20, 2005 11:22 AM > > To: Pat Calhoun [pacalhou@cisco.com] > > Cc: James Kempf; Ted Lemon; Darren Loher; troy@twisted.net; > > capwap@frascone.com > > Subject: Re: [Capwap] RE: IPR issues > > > > Pat, > > > > Your statement that "LWAPP is royalty free" has a huge > > condition applied to it. It is only "royalty free" for a > > company if it does not assert its own IPR against Cisco, on > > anything and not just its own claims on LWAPP. > > > > As I stated earlier, that means that Cisco is free to steal > > one piece of intellectual property from each company that > > implements LWAPP. > > > > Royalty free would be something like this: > > > > http://www.ietf.org/ietf/IPR/CAST-128-entrust > > > > LWAPP is _NOT ROYALTY FREE_. > > > > Dan. > > > > On Sun, 18 Sep 2005 18:47:57 PDT you wrote > > > That is correct, James. LWAPP is royalty free, while the others > > > (SLAPP, CTP, WiCOP) are under RAND terms. > > > > > > Folks, while I understand the concerns raised on the list, I would > > > like to remind everyone that many technologies developed by > > IETF (any > > > any SDO for that matter) have IPR claims around them. > > Nonetheless, if > > > these technologies address a market need, they end up being > > very successful. > > > > > > Further, there is no guarantee that additional IPR claims > > won't show > > > up at a later date. There are many wireless companies that have no > > > representation in this working group, and given the protocol > > > independence objective of CAPWAP, I wouldn't be surprised if > > > additional IPR is identified at a later date. > > > > > > But just because IPR exists does not make a technology less > > successful. > > > In fact, I would point you to > > > https://datatracker.ietf.org/public/ipr_list.cgi for a > > snapshot of the > > > current IPR claims for all of the IETF work in progress. Many IETF > > > protocols are widely deployed that have IPR claims against > > them, and > > > these are very successful. In fact, if one were to design a WLAN > > > system, chances are one would run into other IPR claims > > that exist out > > > of IEEE, such as Trapeze's claims on 802.11e, 802.11f, 802.11k and > > > 802.11i (the last one being a clear example that patents do > > not stop a > > > protocol's usefulness), and the CAPWAP protocol is just part of the > > > overall WLAN system. > > > > > > As we evaluate specific protocols, they each have their > > pros and cons. > > > In the end, a protocol must be chosen based on its > > completeness, its > > > ability to solve the problem, etc. IPR is just one of many > > criterion > > > that we must deal with during the protocol engineering process. > > > Trying to avoid known patents today does not guarantee a > > patent free > > > protocol by any means, nor does enhancing a lesser protocol. > > > > > > So I would urge the WG to look at IPR as one of many issues > > that must > > > be dealt with in our engineering task ahead of us... > > > > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > > > > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > > > Sent: Thursday, September 15, 2005 11:44 AM > > > > To: Ted Lemon > > > > Cc: Darren Loher; troy@twisted.net; capwap@frascone.com > > > > Subject: Re: [Capwap] RE: IPR issues > > > > > > > > Let's be careful to distinguish which IPR notice we're talking > > > > about. As I read the two disclosures (and I'm not a > > lawyer so take > > > > this for what it's worth), the license associated with > > LWAPP would > > > > be royalty free if it is adopted as a standard, the claimed terms > > > > for the others are RAND, which would not be royality free. > > > > > > > > Have I got that right? > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Ted Lemon" > > > > To: "James Kempf" > > > > Cc: "Darren Loher" ; ; > > > > > > > > Sent: Thursday, September 15, 2005 11:07 AM > > > > Subject: Re: [Capwap] RE: IPR issues > > > > > > > > > > > > On Sep 15, 2005, at 10:30 AM, James Kempf wrote: > > > > > I don't have any problem with a license if it is royalty > > > free, but it > > > > > will certainly cause problems for the OpenSource community. > > > > > > > > The license in this case isn't royalty free. It's "reasonable," > > > > which can mean anything, although in my experience to > > date Cisco has > > > > in fact been reasonable in the sense of the word that I normally > > > > use. The relevant document here is RFC3979, which doesn't > > > > explicitly say what to do, but has a good discussion of > > the issues > > > > involved. > > > > > > > > > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 20 23:25:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHvEP-0002Am-VJ for capwap-archive@megatron.ietf.org; Tue, 20 Sep 2005 23:25:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23615 for ; Tue, 20 Sep 2005 23:25:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B9AB20454; Tue, 20 Sep 2005 23:25:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FCF520429; Tue, 20 Sep 2005 23:25:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80B0620429 for ; Tue, 20 Sep 2005 23:24:13 -0400 (EDT) Received: from oz.twisted.net (oz.twisted.net [69.211.34.241]) by mail.frascone.com (Postfix) with ESMTP id D411920396 for ; Tue, 20 Sep 2005 23:24:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by oz.twisted.net (Postfix) with ESMTP id 2C172599C9F; Tue, 20 Sep 2005 22:35:10 -0500 (CDT) Received: from oz.twisted.net ([127.0.0.1]) by localhost (oz.twisted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54034-09; Tue, 20 Sep 2005 22:35:09 -0500 (CDT) Received: from noodle (sindrome.twisted.net [172.16.0.5]) by oz.twisted.net (Postfix) with ESMTP id ABAAD599BA9; Tue, 20 Sep 2005 22:34:52 -0500 (CDT) Reply-To: From: "Troy Dixler" To: "'Dan Harkins'" , "'Pat Calhoun [pacalhou@cisco.com]'" Cc: "'James Kempf'" , "'Ted Lemon'" , "'Darren Loher'" , , Subject: RE: [Capwap] RE: IPR issues MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcW+UY0r02IzJAp6TcmFwgZ38MnkQQACJHqw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <200509210150.j8L1oClx010755@homebrew.trpz.com> Message-Id: <20050921033452.ABAAD599BA9@oz.twisted.net> X-Virus-Scanned: by amavisd-new at twisted.net X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 20 Sep 2005 22:22:08 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Guys, It's really getting stale watching the personal attacks. This is not = about Dan or Pat and your personal differences. I saw this same thing play = out in Paris and the undertones are clearly unprofessional at this point. This thread is about an important issue involving the outcome of this working group and not about individuals. The fact is we are not standardizing 802.anything in this working group = and quite frankly after all the people that have made their points about how uncomfortable they are with moving forward with the cloud of uncertainty = it appears we have a consensus. Back to the issue, it's pretty clear that we've seen more than 6-7 = people weigh in with various issues surrounding the current language expressed = by Cisco's proposal.=20 There are just a few open questions that Pat needs to address (IMHO). = Pat will you consult with Cisco to change the language on the IPR claims? = Will you make the specific IPR being claimed known to the working group? = These are very simple questions. Please don't sling any mud and just let the working group know the answers. I understand if Cisco does not want to change the language, but I also understand that just about every other = major vendor that actively participates on this mailing list does not feel comfortable with the language used in your IPR claims. I think it's fair to see if Pat can discuss this with Cisco and hear the results. Based on that answer the working group chairs need to make = some decisions in the best interest of the IETF community. -Troy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Dan Harkins > Sent: Tuesday, September 20, 2005 8:50 PM > To: Pat Calhoun [pacalhou@cisco.com] > Cc: James Kempf; Ted Lemon; Darren Loher; troy@twisted.net; > capwap@frascone.com; dlang@cisco.com > Subject: Re: [Capwap] RE: IPR issues >=20 > Pat, >=20 > I can't. I was not aware that language was added to Trapeze's IEEE > letters of assurance. To be fair that is an alternate licensing > strategy, the previous paragraph states that Trapeze Networks will > offer a non-exclusive license on "reasonable and non-discriminatory > terms" provided similar terms are given to Trapeze Networks (which is > what I understood the letters to state). But also, to be fair, there > is language in there that is, for all intents-and-purposes, exactly > the same as LWAPP's IPR licensing language. Needless to say, I am > surprised and upset. >=20 > Are Airespace's/Cisco's claims in 11e, 11i, 11k, 11n, 11r any > different? I'd wager that that language was added because that's > the same terms other companies were offering their IEEE-related IPR > for. Lawyers tend to meet at bottom, and if other IEEE letters of > assurance had that language then that's probably the reason it was > added to our's. That is not a rhetorical question by the way. Please > tell me what the terms are of Airespace's/Cisco's claims for the 5 > areas of 802.11 technology that any implementation of CAPWAP would > need to also implement. >=20 > Also, my imaginary scenarios are not attempts by your firm (or > apparently my firm!) to limit participation. It is that it invites > patent poaching (is that less pejorative?) since cross licensing is > the logical result of _ANY_ assertion of IPR. >=20 > Yes, IPR claims against successful technologies have not hindered > that technology. IPR claims against technologies have also not been > enforced. I refer to a Cisco employee standing up in the VRRP BOF > saying that Cisco's HSRP patents precluded any unencumbered = implementation > of VRRP and that Cisco would assert those patents against anyone who > implemented VRRP. To my knowledge Cisco has not asserted those patents > against anyone who implemented VRRP. But, as with purchases of stock, > past performance does not guarantee future performance. >=20 > Dan. >=20 > On Tue, 20 Sep 2005 16:46:58 PDT you wrote > > Dan, > > > > Given you keep bringing up this point, could I possibly ask how you > > differentiate the LWAPP IPR licensing language from Trapeze's IPR > > statement on 802.11e, 802.11f, 802.11k and 802.11i, which I quote: > > > > "... said royalty-free license shall terminate should the licensee > > assert any intellectual property claims against Trapeze Networks". > > > > Just to be clear, your firm has used the exact same language in at = least > > four scenarios that I am aware of, so clearly the LWAPP statement is > > really not that unusual - is it? > > > > So once more, you can cook up a plethora of imaginary scenarios = where my > > firm attempts to limit others from participating in this space, but = the > > reality is this does not represent past, or current, behavior. Once > > more, I point you to = https://datatracker.ietf.org/public/ipr_list.cgi > > which includes a variety of examples where Cisco (not to mention = other > > firms) have IPR claims against successful technologies, and = ironically > > enough, the presence of IPR has not stopped companies from = innovating, > > or being successful. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Tuesday, September 20, 2005 11:22 AM > > > To: Pat Calhoun [pacalhou@cisco.com] > > > Cc: James Kempf; Ted Lemon; Darren Loher; troy@twisted.net; > > > capwap@frascone.com > > > Subject: Re: [Capwap] RE: IPR issues > > > > > > Pat, > > > > > > Your statement that "LWAPP is royalty free" has a huge > > > condition applied to it. It is only "royalty free" for a > > > company if it does not assert its own IPR against Cisco, on > > > anything and not just its own claims on LWAPP. > > > > > > As I stated earlier, that means that Cisco is free to steal > > > one piece of intellectual property from each company that > > > implements LWAPP. > > > > > > Royalty free would be something like this: > > > > > > http://www.ietf.org/ietf/IPR/CAST-128-entrust > > > > > > LWAPP is _NOT ROYALTY FREE_. > > > > > > Dan. > > > > > > On Sun, 18 Sep 2005 18:47:57 PDT you wrote > > > > That is correct, James. LWAPP is royalty free, while the others > > > > (SLAPP, CTP, WiCOP) are under RAND terms. > > > > > > > > Folks, while I understand the concerns raised on the list, I = would > > > > like to remind everyone that many technologies developed by > > > IETF (any > > > > any SDO for that matter) have IPR claims around them. > > > Nonetheless, if > > > > these technologies address a market need, they end up being > > > very successful. > > > > > > > > Further, there is no guarantee that additional IPR claims > > > won't show > > > > up at a later date. There are many wireless companies that have = no > > > > representation in this working group, and given the protocol > > > > independence objective of CAPWAP, I wouldn't be surprised if > > > > additional IPR is identified at a later date. > > > > > > > > But just because IPR exists does not make a technology less > > > successful. > > > > In fact, I would point you to > > > > https://datatracker.ietf.org/public/ipr_list.cgi for a > > > snapshot of the > > > > current IPR claims for all of the IETF work in progress. Many = IETF > > > > protocols are widely deployed that have IPR claims against > > > them, and > > > > these are very successful. In fact, if one were to design a WLAN > > > > system, chances are one would run into other IPR claims > > > that exist out > > > > of IEEE, such as Trapeze's claims on 802.11e, 802.11f, 802.11k = and > > > > 802.11i (the last one being a clear example that patents do > > > not stop a > > > > protocol's usefulness), and the CAPWAP protocol is just part of = the > > > > overall WLAN system. > > > > > > > > As we evaluate specific protocols, they each have their > > > pros and cons. > > > > In the end, a protocol must be chosen based on its > > > completeness, its > > > > ability to solve the problem, etc. IPR is just one of many > > > criterion > > > > that we must deal with during the protocol engineering process. > > > > Trying to avoid known patents today does not guarantee a > > > patent free > > > > protocol by any means, nor does enhancing a lesser protocol. > > > > > > > > So I would urge the WG to look at IPR as one of many issues > > > that must > > > > be dealt with in our engineering task ahead of us... > > > > > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: capwap-admin@frascone.com > > > > > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > > > > Sent: Thursday, September 15, 2005 11:44 AM > > > > > To: Ted Lemon > > > > > Cc: Darren Loher; troy@twisted.net; capwap@frascone.com > > > > > Subject: Re: [Capwap] RE: IPR issues > > > > > > > > > > Let's be careful to distinguish which IPR notice we're talking > > > > > about. As I read the two disclosures (and I'm not a > > > lawyer so take > > > > > this for what it's worth), the license associated with > > > LWAPP would > > > > > be royalty free if it is adopted as a standard, the claimed = terms > > > > > for the others are RAND, which would not be royality free. > > > > > > > > > > Have I got that right? > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ted Lemon" > > > > > To: "James Kempf" > > > > > Cc: "Darren Loher" ; = ; > > > > > > > > > > Sent: Thursday, September 15, 2005 11:07 AM > > > > > Subject: Re: [Capwap] RE: IPR issues > > > > > > > > > > > > > > > =12On Sep 15, 2005, at 10:30 AM, James Kempf wrote: > > > > > > I don't have any problem with a license if it is royalty > > > > free, but it > > > > > > will certainly cause problems for the OpenSource community. > > > > > > > > > > The license in this case isn't royalty free. It's = "reasonable," > > > > > which can mean anything, although in my experience to > > > date Cisco has > > > > > in fact been reasonable in the sense of the word that I = normally > > > > > use. The relevant document here is RFC3979, which doesn't > > > > > explicitly say what to do, but has a good discussion of > > > the issues > > > > > involved. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 05:20:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI0lw-0001Bw-4l for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 05:20:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07354 for ; Wed, 21 Sep 2005 05:20:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E668620429; Wed, 21 Sep 2005 05:20:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CA7DD1FE11; Wed, 21 Sep 2005 05:20:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E403C1FE11 for ; Wed, 21 Sep 2005 05:19:50 -0400 (EDT) Received: from mail.citiz.net (ws19.citiz.net [218.1.66.104]) by mail.frascone.com (Postfix) with SMTP id 953F31FE0E for ; Wed, 21 Sep 2005 05:19:37 -0400 (EDT) Received: (umta 20776 invoked by alias); 21 Sep 2005 09:19:18 -0000 X-Lasthop: 220.248.34.214 Received: from unknown (HELO gwaf7229373f19) (unknown@220.248.34.214) by localhost with SMTP; 21 Sep 2005 09:19:18 -0000 Message-ID: <005b01c5be8d$d56af570$b200160a@gwaf7229373f19> From: "Cliff Zhang" To: "capwap" MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] The question about the configuration request and response Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 17:21:11 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: base64 R3V5cywNCiAgIEkgZm91bmQgbWFueSBtaXN0YWtlcyBpbiBkcmFmdC1vaGFyYS1jYXB3YXAtbHdh cHAtMDMgLHdoaWNoIG1vc3QgYXJlIGFwcGFyZW50IGFuZCBkb24ndCBhZmZlY3QgbXkgbWVhbmlu Zy4NCiAgICBIb3dldmVyLEkgYW0gY29uZnVzZWQgdG8gdGhlICBjb25maWd1cmF0aW9uIHJlcXVl c3QgYW5kIHJlc3BvbnNlIC5UaGUgZnJvbnQgcGFydHMgb2YgdGhlIGRvY3VtZW50IHJlcHJlc2Vu dGVkIHRoYXQgOg0KICAgIDEuV1RQIHNlbnQgdGhlIGNvbmZpZyBSRVEgcGFja2V0IHRvIEFDIGZp cnN0bHk7DQogICAgMi5UaGVuLEFDIHJlc3BvbnNlZCB3aXRoIENvbmZpZyBSRVMgcGFja2V0Lg0K ICAgIEJ1dCBpbiAiMTEuOC4yICBJRUVFIDgwMi4xMSBXTEFOIENvbmZpZyBSZXNwb25zZSIgc2Vj dGlvbix0aGVyZSBpcyBzdGF0ZW1lbnQgYXMgZm9sbG93aW5nOg0KICAgICJUaGUgSUVFRSA4MDIu MTEgV0xBTiBDb25maWd1cmF0aW9uIFJlc3BvbnNlIGlzIHNlbnQgYnkgdGhlIFdUUCB0byB0aGUN CiAgIEFDIGFzIGFuIGFja25vd2xlZGdlbWVudCBvZiB0aGUgcmVjZWlwdCBvZiBhbiBJRUVFIDgw Mi4xMSBXTEFODQogICBDb25maWd1cmF0aW9uIFJlcXVlc3QuIg0KDQogICBDbGVhcmx5LGl0IGlz IGluY29uc2lzdGVudCB3aXRoIHRoZSBlYXJseSBjb250ZW50cy5JIGRvbid0IGtub3cgdGhhdCBp dCBpcyBhIEVSUk9SICxvciBleGlzdHMgdGhlIG90aGVyIGV4cGxhaW5pbmcuDQogICAgV2hvIGNh biBoZWxwIG1lPw0KICAgIFRoYW5rcyBhaGVhZCENCg0KICAgIA0KQmVzdCBSZWdhcmRzLA0KQ2xp ZmYgWmhhbmc= _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 08:33:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI3mj-0001HN-1Q for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 08:33:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16327 for ; Wed, 21 Sep 2005 08:33:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 382C820396; Wed, 21 Sep 2005 08:33:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38F2120263; Wed, 21 Sep 2005 08:33:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EBD5220263 for ; Wed, 21 Sep 2005 08:33:00 -0400 (EDT) Received: from huawei.com (szxga02-in.huawei.com [61.144.161.54]) by mail.frascone.com (Postfix) with ESMTP id BD2D71FE0E for ; Wed, 21 Sep 2005 08:32:58 -0400 (EDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IN600LI9389FS@szxga02-in.huawei.com> for capwap@frascone.com; Wed, 21 Sep 2005 20:40:57 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IN6003F9389HR@szxga02-in.huawei.com> for capwap@frascone.com; Wed, 21 Sep 2005 20:40:57 +0800 (CST) Received: from dell60 ([10.18.4.207]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IN600I5Z3805D@szxml02-in.huawei.com>; Wed, 21 Sep 2005 20:40:49 +0800 (CST) From: sujay Subject: RE: [Capwap] The question about the configuration request and response In-reply-to: <005b01c5be8d$d56af570$b200160a@gwaf7229373f19> To: "'Cliff Zhang'" , "'capwap'" Message-id: <001101c5bea8$b738e6f0$cf04120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 18:03:47 +0530 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Guess this helps, 1) WTP --- > Config Req(lwapp) msg --> AC 2) WTP <--- Config Resp(lwapp) msg -- AC 3) user on AC configs a WLAN domain ! WTP <--- Config Update Req (lwapp) msg + 802.11 Config Req msg TLV (ex: = Add WLAN) --- AC 4) WTP ---- Config Update Resp(lwapp) msg + 802.11 Config Resp msg TLV = (just an ACK) ---> AC Regards, ~Sujay -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Cliff Zhang Sent: Wednesday, September 21, 2005 2:51 PM To: capwap Subject: [Capwap] The question about the configuration request and = response Guys, I found many mistakes in draft-ohara-capwap-lwapp-03 ,which most are = apparent and don't affect my meaning. However,I am confused to the configuration request and response = .The front parts of the document represented that : 1.WTP sent the config REQ packet to AC firstly; 2.Then,AC responsed with Config RES packet. But in "11.8.2 IEEE 802.11 WLAN Config Response" section,there is = statement as following: "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." Clearly,it is inconsistent with the early contents.I don't know that = it is a ERROR ,or exists the other explaining. Who can help me? Thanks ahead! =20 Best Regards, Cliff Zhang = =E7=8C=A8=E6=AA=B4X=E4=BF=8B?=E8=81=94=EE=84=A4=EE=95=9D=EE=95=8Em=E7=A8=9B= =EF=A3=B5=E6=AB=92=EE=9A=84=E5=86=ACr=E5=A4=80r=E5=A3=99=E6=AB=92=EE=9A=9E= ??-=E5=A6=9B=E6=A4=A0=E8=AD=AC _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 12:17:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7HY-0002d2-Bg for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 12:17:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02268 for ; Wed, 21 Sep 2005 12:17:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B8ED32027E; Wed, 21 Sep 2005 12:17:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78E1C20425; Wed, 21 Sep 2005 12:17:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0258D20425 for ; Wed, 21 Sep 2005 12:16:49 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id ED7292027E for ; Wed, 21 Sep 2005 12:16:46 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8LGGisf017164 for ; Wed, 21 Sep 2005 11:16:44 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Sep 2005 18:16:43 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550815B1E5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: capwap@frascone.com Subject: RE: [Capwap] A note on IPR issues MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 18:16:39 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Can I ask all WG participants to refrain from accusations and/or playing amateur lawyer. It is not appropriate to speak (I think) to accuse people of intentions that you suspect. If you have proof of bad intentions, pls send such proof to the chairs and the AD, but don't start discussions here about things you have no proof of. Let me (as AD) go and dive into the exact process we need to follow here. I will probably need a few days to do a proper job. You can all do the same if you want to be prepared when I post my findings. An important RFC to read is RFC3669. in addition to RFC3978 and 3979. Meanwhile, people who have somthing to disclose can continue to do so. It is also fine to try and converge on consensus about a question like: - does the WG want to continue work on a CAPWAP protocol that probably will have IPR claims against it> - does the WG want to try to change course and define a CAPWAP protocol from scratch, trying to avoid any IPR claims - does the working group rather close down and nopt work on a standards track CAPWAP protocol? Bert -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf Of Mani, Mahalingam (Mahalingam) Sent: Wednesday, September 21, 2005 00:11 To: capwap@frascone.com Subject: [Capwap] A note on IPR issues The AD has pointed out the need to and usefulness of disclosing all IPR that there may be or known to be existing out there. In addition - the chairs would urge the disclosures to be as detailed as can be in order to facilitate the WG to decide its course of action among the many options this may lead to in terms of adoption of a protocol that the WG can come to a consensus on - an acceptable base protocol and work further to get to an interoperable CAPWAP protocol. An example of a clear (detailed) one is the ID#144 that points to related enough information for WG to review and form an opinion. So - whether it is being expansive in scope - it will be indeed useful to the WG which has appeared to approach getting to a CAPWAP protocol based on work done so far in the WG & evaluation exercise and WG's review of it. -mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 12:19:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7JR-0003xq-HI for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 12:19:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02440 for ; Wed, 21 Sep 2005 12:19:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2A72D2045E; Wed, 21 Sep 2005 12:19:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F67A2043D; Wed, 21 Sep 2005 12:19:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06EA92027E for ; Wed, 21 Sep 2005 12:18:59 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by mail.frascone.com (Postfix) with ESMTP id 1DF5F20396 for ; Wed, 21 Sep 2005 12:18:54 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8LGGYi6026693; Wed, 21 Sep 2005 19:16:35 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 19:18:33 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 11:18:22 -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] RE: IPR issues/Close of Thread Message-ID: <893AE265F4ADF94AB7FB26D31A788E4101077F68@mvebe101.NOE.Nokia.com> Thread-Topic: [Capwap] RE: IPR issues/Close of Thread Thread-Index: AcW+UY0r02IzJAp6TcmFwgZ38MnkQQACJHqwABqR0LA= From: To: , , Cc: , , , , X-OriginalArrivalTime: 21 Sep 2005 16:18:22.0515 (UTC) FILETIME=[1633B030:01C5BEC8] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 09:18:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable =20 Agreed, this tread and the resulting company attacks is getting out of hand. Please keep the discussion civil. The IETF cannot force disclosure on any patent claims other disclosing that they exist. Unfortunately all four protocol have RAND disclosures against them. IPR is just one issue in deciding whether to adopt a technology. The only issue under discussion is how critical the IPR issue is to CAPWAP. =20 Thanks, Dorothy=20 From RFC 3669: 5.4. Patents versus Pending Patents Applied For > =20 > The IETF does not (cannot) expect IPR claimants to tell a working > group specifically how they think a particular patent applies. If a > patent has already been granted, the IETF can reasonably expect > disclosure of the patent number and possibly the relevant IETF > document sections, which will allow working group participants to > explore details of the claims. If a patent has not yet been granted > (or if knowledge of the patent is restricted, e.g., for security > reasons), significantly less information is available. In most > countries patent applications are published 18 months after they are > filed, but in the USA that can be avoided if the applicant does not > also file outside the USA. In some countries applications are a > matter of public record, but details of pending claims can be > modified at any time by the claim submitter before the patent is > granted. It is not known before then what rights will actually be > granted. Finally, rights can be contested in court, and nothing is > final until the courts decide -- perhaps not even then. All the IETF > can expect regarding a pending patent is disclosure that it exists, > the related IETF documents, and possibly the relevant IETF document > sections and some statement about licensing terms. > =20 > =20 > =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of ext Troy Dixler Sent: Tuesday, September 20, 2005 8:22 PM To: 'Dan Harkins'; 'Pat Calhoun [pacalhou@cisco.com]' Cc: 'James Kempf'; 'Ted Lemon'; 'Darren Loher'; capwap@frascone.com; dlang@cisco.com Subject: RE: [Capwap] RE: IPR issues=20 Guys, It's really getting stale watching the personal attacks. This is not about Dan or Pat and your personal differences. I saw this same thing play out in Paris and the undertones are clearly unprofessional at this point. This thread is about an important issue involving the outcome of this working group and not about individuals. The fact is we are not standardizing 802.anything in this working group and quite frankly after all the people that have made their points about how uncomfortable they are with moving forward with the cloud of uncertainty it appears we have a consensus. Back to the issue, it's pretty clear that we've seen more than 6-7 people weigh in with various issues surrounding the current language expressed by Cisco's proposal.=20 There are just a few open questions that Pat needs to address (IMHO). Pat will you consult with Cisco to change the language on the IPR claims? Will you make the specific IPR being claimed known to the working group? These are very simple questions. Please don't sling any mud and just let the working group know the answers. I understand if Cisco does not want to change the language, but I also understand that just about every other major vendor that actively participates on this mailing list does not feel comfortable with the language used in your IPR claims. I think it's fair to see if Pat can discuss this with Cisco and hear the results. Based on that answer the working group chairs need to make some decisions in the best interest of the IETF community. -Troy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 > Behalf Of Dan Harkins > Sent: Tuesday, September 20, 2005 8:50 PM > To: Pat Calhoun [pacalhou@cisco.com] > Cc: James Kempf; Ted Lemon; Darren Loher; troy@twisted.net;=20 > capwap@frascone.com; dlang@cisco.com > Subject: Re: [Capwap] RE: IPR issues >=20 > Pat, >=20 > I can't. I was not aware that language was added to Trapeze's IEEE=20 > letters of assurance. To be fair that is an alternate licensing=20 > strategy, the previous paragraph states that Trapeze Networks will=20 > offer a non-exclusive license on "reasonable and non-discriminatory=20 > terms" provided similar terms are given to Trapeze Networks (which is=20 > what I understood the letters to state). But also, to be fair, there=20 > is language in there that is, for all intents-and-purposes, exactly=20 > the same as LWAPP's IPR licensing language. Needless to say, I am=20 > surprised and upset. >=20 > Are Airespace's/Cisco's claims in 11e, 11i, 11k, 11n, 11r any=20 > different? I'd wager that that language was added because that's the=20 > same terms other companies were offering their IEEE-related IPR for.=20 > Lawyers tend to meet at bottom, and if other IEEE letters of assurance > had that language then that's probably the reason it was added to=20 > our's. That is not a rhetorical question by the way. Please tell me=20 > what the terms are of Airespace's/Cisco's claims for the 5 areas of=20 > 802.11 technology that any implementation of CAPWAP would need to also > implement. >=20 > Also, my imaginary scenarios are not attempts by your firm (or=20 > apparently my firm!) to limit participation. It is that it invites=20 > patent poaching (is that less pejorative?) since cross licensing is=20 > the logical result of _ANY_ assertion of IPR. >=20 > Yes, IPR claims against successful technologies have not hindered=20 > that technology. IPR claims against technologies have also not been=20 > enforced. I refer to a Cisco employee standing up in the VRRP BOF=20 > saying that Cisco's HSRP patents precluded any unencumbered=20 > implementation of VRRP and that Cisco would assert those patents=20 > against anyone who implemented VRRP. To my knowledge Cisco has not=20 > asserted those patents against anyone who implemented VRRP. But, as=20 > with purchases of stock, past performance does not guarantee future performance. >=20 > Dan. >=20 > On Tue, 20 Sep 2005 16:46:58 PDT you wrote > > Dan, > > > > Given you keep bringing up this point, could I possibly ask how you=20 > > differentiate the LWAPP IPR licensing language from Trapeze's IPR=20 > > statement on 802.11e, 802.11f, 802.11k and 802.11i, which I quote: > > > > "... said royalty-free license shall terminate should the licensee=20 > > assert any intellectual property claims against Trapeze Networks". > > > > Just to be clear, your firm has used the exact same language in at=20 > > least four scenarios that I am aware of, so clearly the LWAPP=20 > > statement is really not that unusual - is it? > > > > So once more, you can cook up a plethora of imaginary scenarios=20 > > where my firm attempts to limit others from participating in this=20 > > space, but the reality is this does not represent past, or current,=20 > > behavior. Once more, I point you to=20 > > https://datatracker.ietf.org/public/ipr_list.cgi > > which includes a variety of examples where Cisco (not to mention=20 > > other > > firms) have IPR claims against successful technologies, and=20 > > ironically enough, the presence of IPR has not stopped companies=20 > > from innovating, or being successful. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@trpz.com] > > > Sent: Tuesday, September 20, 2005 11:22 AM > > > To: Pat Calhoun [pacalhou@cisco.com] > > > Cc: James Kempf; Ted Lemon; Darren Loher; troy@twisted.net; > > > capwap@frascone.com > > > Subject: Re: [Capwap] RE: IPR issues > > > > > > Pat, > > > > > > Your statement that "LWAPP is royalty free" has a huge > > > condition applied to it. It is only "royalty free" for a > > > company if it does not assert its own IPR against Cisco, on > > > anything and not just its own claims on LWAPP. > > > > > > As I stated earlier, that means that Cisco is free to steal > > > one piece of intellectual property from each company that > > > implements LWAPP. > > > > > > Royalty free would be something like this: > > > > > > http://www.ietf.org/ietf/IPR/CAST-128-entrust > > > > > > LWAPP is _NOT ROYALTY FREE_. > > > > > > Dan. > > > > > > On Sun, 18 Sep 2005 18:47:57 PDT you wrote > > > > That is correct, James. LWAPP is royalty free, while the others > > > > (SLAPP, CTP, WiCOP) are under RAND terms. > > > > > > > > Folks, while I understand the concerns raised on the list, I would > > > > like to remind everyone that many technologies developed by > > > IETF (any > > > > any SDO for that matter) have IPR claims around them. > > > Nonetheless, if > > > > these technologies address a market need, they end up being > > > very successful. > > > > > > > > Further, there is no guarantee that additional IPR claims > > > won't show > > > > up at a later date. There are many wireless companies that have no > > > > representation in this working group, and given the protocol > > > > independence objective of CAPWAP, I wouldn't be surprised if > > > > additional IPR is identified at a later date. > > > > > > > > But just because IPR exists does not make a technology less > > > successful. > > > > In fact, I would point you to > > > > https://datatracker.ietf.org/public/ipr_list.cgi for a > > > snapshot of the > > > > current IPR claims for all of the IETF work in progress. Many IETF > > > > protocols are widely deployed that have IPR claims against > > > them, and > > > > these are very successful. In fact, if one were to design a WLAN > > > > system, chances are one would run into other IPR claims > > > that exist out > > > > of IEEE, such as Trapeze's claims on 802.11e, 802.11f, 802.11k and > > > > 802.11i (the last one being a clear example that patents do > > > not stop a > > > > protocol's usefulness), and the CAPWAP protocol is just part of the > > > > overall WLAN system. > > > > > > > > As we evaluate specific protocols, they each have their > > > pros and cons. > > > > In the end, a protocol must be chosen based on its > > > completeness, its > > > > ability to solve the problem, etc. IPR is just one of many > > > criterion > > > > that we must deal with during the protocol engineering process. > > > > Trying to avoid known patents today does not guarantee a > > > patent free > > > > protocol by any means, nor does enhancing a lesser protocol. > > > > > > > > So I would urge the WG to look at IPR as one of many issues > > > that must > > > > be dealt with in our engineering task ahead of us... > > > > > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: capwap-admin@frascone.com > > > > > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > > > > Sent: Thursday, September 15, 2005 11:44 AM > > > > > To: Ted Lemon > > > > > Cc: Darren Loher; troy@twisted.net; capwap@frascone.com > > > > > Subject: Re: [Capwap] RE: IPR issues > > > > > > > > > > Let's be careful to distinguish which IPR notice we're talking > > > > > about. As I read the two disclosures (and I'm not a > > > lawyer so take > > > > > this for what it's worth), the license associated with > > > LWAPP would > > > > > be royalty free if it is adopted as a standard, the claimed terms > > > > > for the others are RAND, which would not be royality free. > > > > > > > > > > Have I got that right? > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Ted Lemon" > > > > > To: "James Kempf" > > > > > Cc: "Darren Loher" ; ; > > > > > > > > > > Sent: Thursday, September 15, 2005 11:07 AM > > > > > Subject: Re: [Capwap] RE: IPR issues > > > > > > > > > > > > > > > =12On Sep 15, 2005, at 10:30 AM, James Kempf wrote: > > > > > > I don't have any problem with a license if it is royalty > > > > free, but it > > > > > > will certainly cause problems for the OpenSource community. > > > > > > > > > > The license in this case isn't royalty free. It's "reasonable," > > > > > which can mean anything, although in my experience to > > > date Cisco has > > > > > in fact been reasonable in the sense of the word that I normally > > > > > use. The relevant document here is RFC3979, which doesn't > > > > > explicitly say what to do, but has a good discussion of > > > the issues > > > > > involved. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 14:27:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9JJ-0001HI-7O for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 14:27:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09366 for ; Wed, 21 Sep 2005 14:27:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 078E520477; Wed, 21 Sep 2005 14:27:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67D4F20440; Wed, 21 Sep 2005 14:27:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D165C20440 for ; Wed, 21 Sep 2005 14:26:18 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id A611820425 for ; Wed, 21 Sep 2005 14:26:15 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 21 Sep 2005 11:26:15 -0700 X-IronPort-AV: i="3.97,132,1125903600"; d="scan'208"; a="344105312:sNHT85103212" 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 j8LIPg4x011583; Wed, 21 Sep 2005 11:26:13 -0700 (PDT) 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, 21 Sep 2005 11:26:10 -0700 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] A note on IPR issues Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2AD62CB@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] A note on IPR issues Thread-Index: AcW+2DZsr6nJdS+1RguFfJrQmOTRGwAAKIVw From: "Pat Calhoun [pacalhou@cisco.com]" To: "James Kempf" , "Wijnen, Bert (Bert)" , X-OriginalArrivalTime: 21 Sep 2005 18:26:10.0319 (UTC) FILETIME=[F091B9F0:01C5BED9] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 11:26:08 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable > > - does the WG want to continue work on a CAPWAP protocol=20 > that probably > > will have IPR claims against it> >=20 > Yes, provided the release to IETF follows RFC 1822 (royalty free) James,=20 Out of curiosity, could you help me understand what you believe the differences are between the LWAPP IPR disclosure and RFC 1822? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 14:34:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9Q7-0003sG-Pj for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 14:34:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09952 for ; Wed, 21 Sep 2005 14:34:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 56E272045E; Wed, 21 Sep 2005 14:34:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FEA320440; Wed, 21 Sep 2005 14:34:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0DC1520440 for ; Wed, 21 Sep 2005 14:33:48 -0400 (EDT) Received: from WNIMAIL.WoodsideNet.Com (wnifwl.woodsidenet.com [65.192.186.2]) by mail.frascone.com (Postfix) with ESMTP id BBCDB20425 for ; Wed, 21 Sep 2005 14:33:46 -0400 (EDT) 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] A note on IPR issues Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1207E78F50@wnimail.WoodsideNet.Com> Thread-Topic: [Capwap] A note on IPR issues Thread-Index: AcW+x+/SKNZ7nLj2Sa+Z0wvNmYzI8QAEtF6A From: "Paul Lambert" To: "Wijnen, Bert (Bert)" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 11:33:33 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable =20 > - does the WG want to try to change course and define a=20 > CAPWAP protocol > from scratch, trying to avoid any IPR claims There might be some interesting 'non-scratch' approaches that reuse existing IETF protocols. Paul _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 14:51:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9gZ-000111-Am for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 14:51:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11119 for ; Wed, 21 Sep 2005 14:51:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC7B120479; Wed, 21 Sep 2005 14:51:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0DE8020454; Wed, 21 Sep 2005 14:51:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0350C20454 for ; Wed, 21 Sep 2005 14:50:36 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 7EBBB20377 for ; Wed, 21 Sep 2005 14:50:33 -0400 (EDT) Message-ID: <069901c5bedd$57f7bab0$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pat Calhoun [pacalhou@cisco.com]" , "Wijnen, Bert (Bert)" , References: <4FF84B0BC277FF45AA27FE969DD956A2AD62CB@xmb-sjc-235.amer.cisco.com> Subject: Re: [Capwap] A note on IPR issues MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 11:50:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Pat, If you read my note, I did not say that the LWAPP disclosure did not match RFC 1822. I just said that any IPR the WG accepted should be released in that manner. But if you want my opinion about LWAPP... Looking at RFC 1822 and the Cisco disclosure for LWAPP, they look substantially the same. However, since I'm not a lawyer, take this for what it is worth.There might be some subtle points to the difference in wording that I'm missing which make a big difference. jak ----- Original Message ----- From: "Pat Calhoun [pacalhou@cisco.com]" To: "James Kempf" ; "Wijnen, Bert (Bert)" ; Sent: Wednesday, September 21, 2005 11:26 AM Subject: RE: [Capwap] A note on IPR issues > > - does the WG want to continue work on a CAPWAP protocol > that probably > > will have IPR claims against it> > > Yes, provided the release to IETF follows RFC 1822 (royalty free) James, Out of curiosity, could you help me understand what you believe the differences are between the LWAPP IPR disclosure and RFC 1822? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 14:55:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI9kP-0001fn-JU for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 14:55:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11272 for ; Wed, 21 Sep 2005 14:55:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22B4E2048D; Wed, 21 Sep 2005 14:55:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50D962045E; Wed, 21 Sep 2005 14:55:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F0E272045E for ; Wed, 21 Sep 2005 14:54:31 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id AA7EE20377 for ; Wed, 21 Sep 2005 14:54:28 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 21 Sep 2005 11:54:24 -0700 X-IronPort-AV: i="3.97,132,1125903600"; d="scan'208"; a="213653487:sNHT30149344" 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 j8LIsD50008674; Wed, 21 Sep 2005 11:54:19 -0700 (PDT) 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, 21 Sep 2005 11:54:16 -0700 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] A note on IPR issues Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2AD62EF@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] A note on IPR issues Thread-Index: AcW+3Y12D1hOOJIaQIK+EuI1Z2CL+QAABPOw From: "Pat Calhoun [pacalhou@cisco.com]" To: "James Kempf" , "Wijnen, Bert (Bert)" , X-OriginalArrivalTime: 21 Sep 2005 18:54:16.0416 (UTC) FILETIME=[DD8FB600:01C5BEDD] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 11:54:15 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Oh, I realize your question was generic. I was just trying to get your take on the LWAPP comparison. Thanks for your view, Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > Sent: Wednesday, September 21, 2005 11:51 AM > To: Pat Calhoun [pacalhou@cisco.com]; Wijnen, Bert (Bert);=20 > capwap@frascone.com > Subject: Re: [Capwap] A note on IPR issues >=20 > Pat, >=20 > If you read my note, I did not say that the LWAPP disclosure=20 > did not match RFC 1822. I just said that any IPR the WG=20 > accepted should be released in that manner. >=20 > But if you want my opinion about LWAPP... >=20 > > Looking at RFC 1822 and the Cisco disclosure for LWAPP, they=20 > look substantially the same. > >=20 > However, since I'm not a lawyer, take this for what it is=20 > worth.There might be some subtle points to the difference in=20 > wording that I'm missing which make a big difference. >=20 > jak >=20 >=20 > ----- Original Message ----- > From: "Pat Calhoun [pacalhou@cisco.com]" > To: "James Kempf" ; "Wijnen, Bert (Bert)"=20 > ; > Sent: Wednesday, September 21, 2005 11:26 AM > Subject: RE: [Capwap] A note on IPR issues >=20 >=20 > > > - does the WG want to continue work on a CAPWAP protocol > > that probably > > > will have IPR claims against it> > > > > Yes, provided the release to IETF follows RFC 1822 (royalty free) >=20 > James, >=20 > Out of curiosity, could you help me understand what you believe the > differences are between the LWAPP IPR disclosure and RFC 1822? >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 16:03:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAoH-0004GU-8a for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 16:03:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18062 for ; Wed, 21 Sep 2005 16:03:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37C0B20479; Wed, 21 Sep 2005 16:03:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3C30620425; Wed, 21 Sep 2005 16:03:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C873F20425 for ; Wed, 21 Sep 2005 16:02:08 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 35D8C20377 for ; Wed, 21 Sep 2005 16:02:05 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 13:06:27 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Sep 2005 13:01:53 -0700 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] A note on IPR issues Message-ID: Thread-Topic: [Capwap] A note on IPR issues Thread-Index: AcW+3Y12D1hOOJIaQIK+EuI1Z2CL+QAABPOwAAILqxA= From: "Darren Loher" To: "Pat Calhoun [pacalhou@cisco.com]" , "James Kempf" , "Wijnen, Bert (Bert)" , X-OriginalArrivalTime: 21 Sep 2005 20:01:53.0639 (UTC) FILETIME=[4FDACF70:01C5BEE7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 13:01:50 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I also support James' recommendation of following RFC1822. I think the main difference is there aren't any exceptions to the unlimited, royalty free grant of rights in RFC 1822, compared to LWAPP IPR disclosure. In addition, the LWAPP disclosure appears to require the implementor obtain a license from Cisco in order to receive royalty free treatment. RFC1822 does not have this restriction. > - does the WG want to try to change course and define a CAPWAP protocol > from scratch, trying to avoid any IPR claims It is difficult to given an informed answer this question because the WG does not know the nature of the IPR claims at hand. =20 > - does the working group rather close down and nopt work on a=20 > standards track CAPWAP protocol? >=20 No, I still strongly believe the industry will benefit from a standards track protocol for configuring and provisioning wireless access points. -- Darren Loher Chief Network Architect Roving Planet, Inc. > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Pat Calhoun [pacalhou@cisco.com] > Sent: Wednesday, September 21, 2005 12:54 PM > To: James Kempf; Wijnen, Bert (Bert); capwap@frascone.com > Subject: RE: [Capwap] A note on IPR issues >=20 > Oh, I realize your question was generic. I was just trying to get your > take on the LWAPP comparison. >=20 > Thanks for your view, >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > Sent: Wednesday, September 21, 2005 11:51 AM > > To: Pat Calhoun [pacalhou@cisco.com]; Wijnen, Bert (Bert); > > capwap@frascone.com > > Subject: Re: [Capwap] A note on IPR issues > > > > Pat, > > > > If you read my note, I did not say that the LWAPP disclosure > > did not match RFC 1822. I just said that any IPR the WG > > accepted should be released in that manner. > > > > But if you want my opinion about LWAPP... > > > > > > Looking at RFC 1822 and the Cisco disclosure for LWAPP, they > > look substantially the same. > > > > > > However, since I'm not a lawyer, take this for what it is > > worth.There might be some subtle points to the difference in > > wording that I'm missing which make a big difference. > > > > jak > > > > > > ----- Original Message ----- > > From: "Pat Calhoun [pacalhou@cisco.com]" > > To: "James Kempf" ; "Wijnen, Bert (Bert)" > > ; > > Sent: Wednesday, September 21, 2005 11:26 AM > > Subject: RE: [Capwap] A note on IPR issues > > > > > > > > - does the WG want to continue work on a CAPWAP protocol > > > that probably > > > > will have IPR claims against it> > > > > > > Yes, provided the release to IETF follows RFC 1822 (royalty free) > > > > James, > > > > Out of curiosity, could you help me understand what you believe the > > differences are between the LWAPP IPR disclosure and RFC 1822? > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 16:23:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIB7e-0008F8-Ls for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 16:23:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25340 for ; Wed, 21 Sep 2005 16:23:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CD2D4204C1; Wed, 21 Sep 2005 16:23:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B71B20440; Wed, 21 Sep 2005 16:23:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DAEE20440 for ; Wed, 21 Sep 2005 16:22:29 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 4C7C520427 for ; Wed, 21 Sep 2005 16:22:26 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j8LKG5o3013701; Wed, 21 Sep 2005 13:16:05 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509212016.j8LKG5o3013701@homebrew.trpz.com> To: "Wijnen, Bert (Bert)" Cc: capwap@frascone.com Subject: Re: [Capwap] A note on IPR issues In-Reply-To: Your message of "Wed, 21 Sep 2005 18:16:39 +0200." <7D5D48D2CAA3D84C813F5B154F43B1550815B1E5@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13699.1127333765.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 13:16:05 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Bert, On Wed, 21 Sep 2005 18:16:39 +0200 you wrote > > It is also fine to try and converge on consensus about a question like: > > - does the WG want to continue work on a CAPWAP protocol that probably > will have IPR claims against it> There are examples of IETF protocols having IPR claims against them but the terms are not uniform. If the terms for the IPR were like licensed royalty-free with no restriction or licensed royalty-free with a very specific field of use then I'd say yes, if not then I'd say no. I don't think the claims against the proposals here are either. The list in section 5.6 of RFC3669 looks to be ordered with a preference that I share. I'd say the cut-off should be between the 4th and 5th, 4 or above (if royalty-free) then yes, 5 or below then no. > - does the WG want to try to change course and define a CAPWAP protocol > from scratch, trying to avoid any IPR claims That would be very difficult at this point-in-time considering we don't know exactly what the claim(s) is/are. Given that some of the proposals are very generic and reuse existing technologies it seems the claim(s) must be quite broad and therefore any work this group did would probably end up being claimed in the same way that CTP, WiCOP, and SLAPP were. > - does the working group rather close down and nopt work on a > standards track CAPWAP protocol? All 4 proposals fall under a single IPR claim but the terms for one are decidedly less onerous than the other three. That seems extremely unfair and it looks like IPR is being used to influence the output of this working group. If we can't return to a level playing field-- where the terms to use all proposals are exactly the same-- then I think we should just close down. Furthermore, if the terms cannot be made less onerous, rise above the line I mentioned above, then I would also reluctantly have to say we should close down. This entire area is so encumbered I have a hard time working to further encumber myself and everyone else (save one). Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 17:25:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIC5Y-0006Jq-D3 for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 17:25:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03404 for ; Wed, 21 Sep 2005 17:25:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B3D46204EB; Wed, 21 Sep 2005 17:25:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F090720440; Wed, 21 Sep 2005 17:25:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2A40620440 for ; Wed, 21 Sep 2005 17:24:35 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 05A5420425 for ; Wed, 21 Sep 2005 17:24:33 -0400 (EDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 21 Sep 2005 14:24:32 -0700 X-IronPort-AV: i="3.97,132,1125903600"; d="scan'208"; a="213702953:sNHT50736630" 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 j8LLO7v8029024; Wed, 21 Sep 2005 14:24:30 -0700 (PDT) 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, 21 Sep 2005 14:24:29 -0700 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] A note on IPR issues Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B33141@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] A note on IPR issues Thread-Index: AcW+3Y12D1hOOJIaQIK+EuI1Z2CL+QAABPOwAAILqxAAAzDY4A== From: "Pat Calhoun [pacalhou@cisco.com]" To: "Darren Loher" , "James Kempf" , "Wijnen, Bert (Bert)" , X-OriginalArrivalTime: 21 Sep 2005 21:24:29.0983 (UTC) FILETIME=[DA10E2F0:01C5BEF2] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 14:24:28 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable > I also support James' recommendation of following RFC1822. I=20 > think the main difference is there aren't any exceptions to=20 > the unlimited, royalty free grant of rights in RFC 1822,=20 > compared to LWAPP IPR disclosure. In addition, the LWAPP=20 > disclosure appears to require the implementor obtain a=20 > license from Cisco in order to receive royalty free=20 > treatment. RFC1822 does not have this restriction. Darren, I understand your concern, but realistically Cisco does not go after people or companies just because they do not go through the formalities of getting a license. Pat Calhoun CTO, Wireless Networking Business Unit=20 Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 17:34:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EICEG-0002Oc-67 for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 17:34:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03844 for ; Wed, 21 Sep 2005 17:34:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9998C20513; Wed, 21 Sep 2005 17:34:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D5884204C1; Wed, 21 Sep 2005 17:34:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0E71F204C1 for ; Wed, 21 Sep 2005 17:33:15 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 983DC20479 for ; Wed, 21 Sep 2005 17:33:12 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j8LLQVrr013923; Wed, 21 Sep 2005 14:26:31 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509212126.j8LLQVrr013923@homebrew.trpz.com> To: "Darren Loher" Cc: "Pat Calhoun [pacalhou@cisco.com]" , "James Kempf" , "Wijnen, Bert (Bert)" , capwap@frascone.com Subject: Re: [Capwap] A note on IPR issues In-Reply-To: Your message of "Wed, 21 Sep 2005 13:01:50 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13921.1127337991.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 14:26:31 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Derren, Another significant difference is that RFC1822 has a specific field of use that applies when the grant of rights terminate ("Photuris or any derivative"), while the LWAPP IPR disclosure has no field of use that applies when the grant of rights terminate. Dan. On Wed, 21 Sep 2005 13:01:50 PDT you wrote > I also support James' recommendation of following RFC1822. I think the > main difference is there aren't any exceptions to the unlimited, royalty > free grant of rights in RFC 1822, compared to LWAPP IPR disclosure. In > addition, the LWAPP disclosure appears to require the implementor obtain > a license from Cisco in order to receive royalty free treatment. RFC1822 > does not have this restriction. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 21 21:35:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIFzU-0004ze-Nh for capwap-archive@megatron.ietf.org; Wed, 21 Sep 2005 21:35:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15494 for ; Wed, 21 Sep 2005 21:35:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B98F20479; Wed, 21 Sep 2005 21:35:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 765CD20230; Wed, 21 Sep 2005 21:35:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 63FDD20230 for ; Wed, 21 Sep 2005 21:34:40 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by mail.frascone.com (Postfix) with ESMTP id 450981FE02 for ; Wed, 21 Sep 2005 21:34:37 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8M1WO8P032757; Thu, 22 Sep 2005 04:32:26 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Sep 2005 04:34:25 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 20:34:22 -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 Message-ID: <893AE265F4ADF94AB7FB26D31A788E410107839E@mvebe101.NOE.Nokia.com> Thread-Topic: CAPWAP evaluation draft complete Thread-Index: AcW/FcI2CZhyH4KQRBqFRs87raP/Xg== From: To: Cc: , , , X-OriginalArrivalTime: 22 Sep 2005 01:34:22.0638 (UTC) FILETIME=[C2627CE0:01C5BF15] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] CAPWAP evaluation draft complete Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 21 Sep 2005 18:34:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable After much hard work, the evaluation team has completed the CAPWAP evaluation draft. Its is available for review at: http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and also in the internet drafts directory. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for CAPWAP protocol moving forward. In addition, a number of recommendations were made which the evaluation team believed should be addressed by the working group. Over the next 2 weeks the evaluation team will address clarification questions on the WG list. The recommendation provided by the evaluation team will not change, as this was intended to be an independent activity supported by the WG. This is essentially a WGLC on the evaluation draft. Please submit any clarification question to the list by Friday, September 30th. The next step will be to come to an agreement on the WG list to decide to accept the recommended protocol. Once we have established consensus, we can further discuss the additional recommendations presented in the draft. We would like to thank the evaluation team on its thorough work and a job well done. Regards, Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 22 13:54:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIVGx-0001ki-6G for capwap-archive@megatron.ietf.org; Thu, 22 Sep 2005 13:54:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13876 for ; Thu, 22 Sep 2005 13:54:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E0B3D20377; Thu, 22 Sep 2005 13:54:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6EC5A202AF; Thu, 22 Sep 2005 13:54:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8DE2F202AF for ; Thu, 22 Sep 2005 13:53:48 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 15CEC2028D for ; Thu, 22 Sep 2005 13:53:45 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 10:57:54 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 10:53:22 -0700 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] A note on IPR issues Message-ID: Thread-Topic: [Capwap] A note on IPR issues Thread-Index: AcW+9BCryVcXjREMRqWLBduYg+sY/QAqLI0g From: "Darren Loher" To: "Dan Harkins" Cc: "Pat Calhoun [pacalhou@cisco.com]" , "James Kempf" , "Wijnen, Bert (Bert)" , X-OriginalArrivalTime: 22 Sep 2005 17:53:22.0190 (UTC) FILETIME=[85E2D2E0:01C5BF9E] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 22 Sep 2005 10:53:27 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thanks for pointing that out Dan. That is also desirable. Perhaps=20 if this represents Cisco's intent, they would be willing to=20 limit the scope of the IPR claim to: 1. claims and rights limitation scope to LWAPP=20 2. specifically state an unlimited, "no license required" stance=20 both of these being similar to the precedent set in RFC1822. =20 Pat, what do you think? These constraints seem compatible with the intent you've been describing. Would you feel comfortable taking these two constraints to Cisco? Also, I know there have been several appeals already, but can you also find out for us if Cisco will allow you to release to specific claims that the disclosures are referring to? I think this would help the working group feel more comfortable dealing with this. -Darren -----Original Message----- From: Dan Harkins [mailto:dharkins@trpz.com] Sent: Wed 9/21/2005 3:26 PM To: Darren Loher Cc: Pat Calhoun [pacalhou@cisco.com]; James Kempf; Wijnen, Bert = (Bert); capwap@frascone.com Subject: Re: [Capwap] A note on IPR issues=20 =20 Derren, Another significant difference is that RFC1822 has a specific field of use that applies when the grant of rights terminate ("Photuris or any derivative"), while the LWAPP IPR disclosure has no field of use that applies when the grant of rights terminate. Dan. On Wed, 21 Sep 2005 13:01:50 PDT you wrote > I also support James' recommendation of following RFC1822. I think = the > main difference is there aren't any exceptions to the unlimited, = royalty > free grant of rights in RFC 1822, compared to LWAPP IPR disclosure. = In > addition, the LWAPP disclosure appears to require the implementor = obtain > a license from Cisco in order to receive royalty free treatment. = RFC1822 > does not have this restriction. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 22 13:57:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIVJr-0002JJ-JD for capwap-archive@megatron.ietf.org; Thu, 22 Sep 2005 13:57:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14072 for ; Thu, 22 Sep 2005 13:57:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90F312039F; Thu, 22 Sep 2005 13:57:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DB0D2031A; Thu, 22 Sep 2005 13:57:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D0F12031A for ; Thu, 22 Sep 2005 13:56:15 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id ABA6A202AF for ; Thu, 22 Sep 2005 13:56:11 -0400 (EDT) Message-ID: <090201c5bf9e$e9903fd0$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , Cc: , , , References: <893AE265F4ADF94AB7FB26D31A788E410107839E@mvebe101.NOE.Nokia.com> Subject: Re: [Capwap] CAPWAP evaluation draft complete MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 22 Sep 2005 10:56:09 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dorothy and Mani, After reading the evaluation document, I support the recommendation of the evaluation team. I hope the WG will be able to resolve the lingering nontechnical issues fairly quickly and move forward with completing the CAPWAP protocol based on the evaluation document's recommendations. I would also suggest that someone with good writing skills do an editing pass through the evaluation document before it is submitted to the IESG, since I noticed numerous typos and minor grammatical errors. jak ----- Original Message ----- From: To: Cc: ; ; ; Sent: Wednesday, September 21, 2005 6:34 PM Subject: [Capwap] CAPWAP evaluation draft complete After much hard work, the evaluation team has completed the CAPWAP evaluation draft. Its is available for review at: http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and also in the internet drafts directory. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for CAPWAP protocol moving forward. In addition, a number of recommendations were made which the evaluation team believed should be addressed by the working group. Over the next 2 weeks the evaluation team will address clarification questions on the WG list. The recommendation provided by the evaluation team will not change, as this was intended to be an independent activity supported by the WG. This is essentially a WGLC on the evaluation draft. Please submit any clarification question to the list by Friday, September 30th. The next step will be to come to an agreement on the WG list to decide to accept the recommended protocol. Once we have established consensus, we can further discuss the additional recommendations presented in the draft. We would like to thank the evaluation team on its thorough work and a job well done. Regards, Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 22 16:47:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIXyS-0005yg-Bg for capwap-archive@megatron.ietf.org; Thu, 22 Sep 2005 16:47:25 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25439 for ; Thu, 22 Sep 2005 16:47:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E649A2046D; Thu, 22 Sep 2005 16:47:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A5F02041E; Thu, 22 Sep 2005 16:47:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 946E62041E for ; Thu, 22 Sep 2005 16:46:00 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 0878620392 for ; Thu, 22 Sep 2005 16:45:58 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 22 Sep 2005 13:45:57 -0700 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 j8MKjm4b001005; Thu, 22 Sep 2005 13:45:54 -0700 (PDT) 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); Thu, 22 Sep 2005 13:45:48 -0700 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] A note on IPR issues Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B335CE@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] A note on IPR issues Thread-Index: AcW+9BCryVcXjREMRqWLBduYg+sY/QAqLI0gAAZrOSA= From: "Pat Calhoun [pacalhou@cisco.com]" To: "Darren Loher" , "Dan Harkins" Cc: "James Kempf" , "Wijnen, Bert (Bert)" , , X-OriginalArrivalTime: 22 Sep 2005 20:45:48.0772 (UTC) FILETIME=[9CEDF240:01C5BFB6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 22 Sep 2005 13:45:48 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Folks, I'm working this in real time, but it is a complex issue and my hectic travel schedule makes it slightly harder. That said, I will provide a statement soon. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 > Sent: Thursday, September 22, 2005 10:53 AM > To: Dan Harkins > Cc: Pat Calhoun [pacalhou@cisco.com]; James Kempf; Wijnen,=20 > Bert (Bert); capwap@frascone.com > Subject: RE: [Capwap] A note on IPR issues=20 >=20 > Thanks for pointing that out Dan. That is also desirable. =20 > Perhaps if this represents Cisco's intent, they would be=20 > willing to limit the scope of the IPR claim to: > 1. claims and rights limitation scope to LWAPP 2.=20 > specifically state an unlimited, "no license required" stance=20 > both of these being similar to the precedent set in RFC1822. =20 >=20 > Pat, what do you think? These constraints seem compatible=20 > with the intent you've been describing. Would you feel=20 > comfortable taking these two constraints to Cisco? >=20 > Also, I know there have been several appeals already, but can=20 > you also find out for us if Cisco will allow you to release=20 > to specific claims that the disclosures are referring to? I=20 > think this would help the working group feel more comfortable=20 > dealing with this. >=20 > -Darren >=20 >=20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com] > Sent: Wed 9/21/2005 3:26 PM > To: Darren Loher > Cc: Pat Calhoun [pacalhou@cisco.com]; James Kempf; Wijnen, =20 > Bert (Bert); capwap@frascone.com > Subject: Re: [Capwap] A note on IPR issues=20 > =20 > Derren, >=20 > Another significant difference is that RFC1822 has a=20 > specific field of use that applies when the grant of rights=20 > terminate ("Photuris or any derivative"), while the LWAPP IPR=20 > disclosure has no field of use that applies when the grant of=20 > rights terminate. >=20 > Dan. >=20 > On Wed, 21 Sep 2005 13:01:50 PDT you wrote > > I also support James' recommendation of following RFC1822. I think=20 > > the main difference is there aren't any exceptions to the=20 > unlimited,=20 > > royalty free grant of rights in RFC 1822, compared to LWAPP IPR=20 > > disclosure. In addition, the LWAPP disclosure appears to=20 > require the=20 > > implementor obtain a license from Cisco in order to receive royalty=20 > > free treatment. RFC1822 does not have this restriction. >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Sep 24 13:03:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJDQg-00041v-9E for capwap-archive@megatron.ietf.org; Sat, 24 Sep 2005 13:03:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13158 for ; Sat, 24 Sep 2005 13:03:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8902202E3; Sat, 24 Sep 2005 13:03:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8DA8C1FD6C; Sat, 24 Sep 2005 13:03:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 975031FD6C for ; Sat, 24 Sep 2005 13:02:50 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id A41461FC5F for ; Sat, 24 Sep 2005 13:02:47 -0400 (EDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 24 Sep 2005 10:02:46 -0700 X-IronPort-AV: i="3.97,143,1125903600"; d="scan'208"; a="214640474:sNHT31691972" 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 j8OH2dVt023074; Sat, 24 Sep 2005 10:02:42 -0700 (PDT) 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); Sat, 24 Sep 2005 10:02:41 -0700 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="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: [Capwap] The question about the configuration request and response Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B33C18@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] The question about the configuration request and response Thread-Index: AcW+qL16tgmRQSWcQYazovzXn6UCbgB3lVhg From: "Pat Calhoun [pacalhou@cisco.com]" To: "sujay" , "Cliff Zhang" , "capwap" X-OriginalArrivalTime: 24 Sep 2005 17:02:41.0794 (UTC) FILETIME=[C67EB620:01C5C129] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sat, 24 Sep 2005 10:02:42 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: base64 U3VqYXksDQoNCllvdSBhcmUgY29ycmVjdC4gQ2xpZmYsIGFwcGFyZW50bHkgeW91IGhhdmUgZm91 bmQgYSBidWcgaW4gbXkgZG9jdW1lbnQsIHdoaWNoIEkgd2lsbCBmaXguDQoNClBhdCBDYWxob3Vu DQpDVE8sIFdpcmVsZXNzIE5ldHdvcmtpbmcgQnVzaW5lc3MgVW5pdA0KQ2lzY28gU3lzdGVtcw0K DQogDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2Fwd2FwLWFkbWlu QGZyYXNjb25lLmNvbSANCj4gW21haWx0bzpjYXB3YXAtYWRtaW5AZnJhc2NvbmUuY29tXSBPbiBC ZWhhbGYgT2Ygc3VqYXkNCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMDUgNToz NCBBTQ0KPiBUbzogJ0NsaWZmIFpoYW5nJzsgJ2NhcHdhcCcNCj4gU3ViamVjdDogUkU6IFtDYXB3 YXBdIFRoZSBxdWVzdGlvbiBhYm91dCB0aGUgY29uZmlndXJhdGlvbiANCj4gcmVxdWVzdCBhbmQg cmVzcG9uc2UNCj4gDQo+IA0KPiBHdWVzcyB0aGlzIGhlbHBzLA0KPiANCj4gMSkNCj4gV1RQIC0t LSA+IENvbmZpZyBSZXEobHdhcHApIG1zZyAtLT4gQUMNCj4gDQo+IDIpDQo+IFdUUCA8LS0tIENv bmZpZyBSZXNwKGx3YXBwKSBtc2cgLS0gQUMNCj4gDQo+IA0KPiAzKSB1c2VyIG9uIEFDIGNvbmZp Z3MgYSBXTEFOIGRvbWFpbiAhDQo+IA0KPiBXVFAgPC0tLSBDb25maWcgVXBkYXRlIFJlcSAobHdh cHApIG1zZyArIDgwMi4xMSBDb25maWcgUmVxIA0KPiBtc2cgVExWIChleDogQWRkIFdMQU4pIC0t LSBBQw0KPiANCj4gNCkNCj4gDQo+IFdUUCAtLS0tIENvbmZpZyBVcGRhdGUgUmVzcChsd2FwcCkg bXNnICsgODAyLjExIENvbmZpZyBSZXNwIA0KPiBtc2cgVExWIChqdXN0IGFuIEFDSykgLS0tPiBB Qw0KPiANCj4gUmVnYXJkcywNCj4gflN1amF5DQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGNhcHdhcC1hZG1pbkBmcmFzY29uZS5jb20gDQo+IFttYWls dG86Y2Fwd2FwLWFkbWluQGZyYXNjb25lLmNvbV0gT24gQmVoYWxmIE9mIENsaWZmIFpoYW5nDQo+ IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDIxLCAyMDA1IDI6NTEgUE0NCj4gVG86IGNhcHdh cA0KPiBTdWJqZWN0OiBbQ2Fwd2FwXSBUaGUgcXVlc3Rpb24gYWJvdXQgdGhlIGNvbmZpZ3VyYXRp b24gDQo+IHJlcXVlc3QgYW5kIHJlc3BvbnNlDQo+IA0KPiANCj4gR3V5cywNCj4gICAgSSBmb3Vu ZCBtYW55IG1pc3Rha2VzIGluIGRyYWZ0LW9oYXJhLWNhcHdhcC1sd2FwcC0wMyANCj4gLHdoaWNo IG1vc3QgYXJlIGFwcGFyZW50IGFuZCBkb24ndCBhZmZlY3QgbXkgbWVhbmluZy4NCj4gICAgIEhv d2V2ZXIsSSBhbSBjb25mdXNlZCB0byB0aGUgIGNvbmZpZ3VyYXRpb24gcmVxdWVzdCBhbmQgDQo+ IHJlc3BvbnNlIC5UaGUgZnJvbnQgcGFydHMgb2YgdGhlIGRvY3VtZW50IHJlcHJlc2VudGVkIHRo YXQgOg0KPiAgICAgMS5XVFAgc2VudCB0aGUgY29uZmlnIFJFUSBwYWNrZXQgdG8gQUMgZmlyc3Rs eTsNCj4gICAgIDIuVGhlbixBQyByZXNwb25zZWQgd2l0aCBDb25maWcgUkVTIHBhY2tldC4NCj4g ICAgIEJ1dCBpbiAiMTEuOC4yICBJRUVFIDgwMi4xMSBXTEFOIENvbmZpZyBSZXNwb25zZSIgDQo+ IHNlY3Rpb24sdGhlcmUgaXMgc3RhdGVtZW50IGFzIGZvbGxvd2luZzoNCj4gICAgICJUaGUgSUVF RSA4MDIuMTEgV0xBTiBDb25maWd1cmF0aW9uIFJlc3BvbnNlIGlzIHNlbnQgYnkgDQo+IHRoZSBX VFAgdG8gdGhlDQo+ICAgIEFDIGFzIGFuIGFja25vd2xlZGdlbWVudCBvZiB0aGUgcmVjZWlwdCBv ZiBhbiBJRUVFIDgwMi4xMSBXTEFODQo+ICAgIENvbmZpZ3VyYXRpb24gUmVxdWVzdC4iDQo+IA0K PiAgICBDbGVhcmx5LGl0IGlzIGluY29uc2lzdGVudCB3aXRoIHRoZSBlYXJseSBjb250ZW50cy5J IGRvbid0IA0KPiBrbm93IHRoYXQgaXQgaXMgYSBFUlJPUiAsb3IgZXhpc3RzIHRoZSBvdGhlciBl eHBsYWluaW5nLg0KPiAgICAgV2hvIGNhbiBoZWxwIG1lPw0KPiAgICAgVGhhbmtzIGFoZWFkIQ0K PiANCj4gICAgIA0KPiBCZXN0IFJlZ2FyZHMsDQo+IENsaWZmIFpoYW5nCeeMqOaqtFjkv4s/6IGU 7oSk7pWd7pWObeeom++jtearku6ahOWGrHLlpIBy5aOZ5quS7pqePz8t5aab5qSg6K2sDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDYXB3 YXAgbWFpbGluZyBsaXN0DQo+IENhcHdhcEBmcmFzY29uZS5jb20NCj4gaHR0cDovL21haWwuZnJh c2NvbmUuY29tL21haWxtYW4vbGlzdGluZm8vY2Fwd2FwDQo+IA0K _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Sep 24 13:06:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJDTY-0004fz-4x for capwap-archive@megatron.ietf.org; Sat, 24 Sep 2005 13:06:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13247 for ; Sat, 24 Sep 2005 13:06:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 786AC202E3; Sat, 24 Sep 2005 13:06:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 860AB1FD6C; Sat, 24 Sep 2005 13:06:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 57D4B1FD6C for ; Sat, 24 Sep 2005 13:06:00 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 1C14C1FC5F for ; Sat, 24 Sep 2005 13:05:57 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2005 10:05:55 -0700 X-IronPort-AV: i="3.97,143,1125903600"; d="scan'208,217"; a="345250681:sNHT49454158" 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 j8OH5o4u012064; Sat, 24 Sep 2005 10:05:51 -0700 (PDT) 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); Sat, 24 Sep 2005 10:05:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C12A.37F56F66" Subject: RE: [Capwap] Doubt Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B33C1A@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Doubt Thread-Index: AcW6rJ7LnWXzfhLUSYCRFLDM/yiXpAGfXsRw From: "Pat Calhoun [pacalhou@cisco.com]" To: , X-OriginalArrivalTime: 24 Sep 2005 17:05:52.0563 (UTC) FILETIME=[3833C030:01C5C12A] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sat, 24 Sep 2005 10:05:52 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C12A.37F56F66 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Sujay, =20 My read of the spec is different from yours. Join->Idle only occurs if the Join response failed for security reasons. Join->Discovery occurs for any other failed Join response (non security related). =20 Hope this helps, =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of ramanathans Sent: Friday, September 16, 2005 3:51 AM To: capwap@frascone.com Subject: [Capwap] Doubt =09 =09 Hi all,=20 I am very new to this LWAPP. When I was reading the STATE DIAGRAM=20 I did not understand when the state transition is from=20 =20 JOIN -------> IDLE and JOIN -----------> DISCOVERY =20 =20 For both of them they gave the same reason for transition. Can anybody explain why? =20 =20 =20 Bye =20 =20 ------_=_NextPart_001_01C5C12A.37F56F66 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Sujay,
 
My read of the spec is different from yours. = Join->Idle=20 only occurs if the Join response failed for security reasons. = Join->Discovery=20 occurs for any other failed Join response (non security=20 related).
 
Hope this helps,
 

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

 

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of=20 ramanathans
Sent: Friday, September 16, 2005 3:51=20 AM
To: capwap@frascone.com
Subject: [Capwap]=20 Doubt

Hi all, =

           = =20 I am very new to this LWAPP. When I was reading the STATE DIAGRAM=20

I did not understand = when the=20 state transition is from

 

JOIN =20 -----à =20 = IDLE           &nb= sp;=20 and    JOIN  ---------à=20 DISCOVERY

 

 

For  both of them = they gave=20 the same  reason for transition. Can anybody explain=20 why?

 

 

 

Bye

 

 

------_=_NextPart_001_01C5C12A.37F56F66-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From Nani@recycler.com Sun Sep 25 06:09:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJTRV-0001Nd-2a for capwap-archive@megatron.ietf.org; Sun, 25 Sep 2005 06:09:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03208 for ; Sun, 25 Sep 2005 06:09:06 -0400 (EDT) Received: from bsw167.neoplus.adsl.tpnet.pl ([83.29.142.167] helo=sunpoint.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EJTYH-0001X8-Rx for capwap-archive@ietf.org; Sun, 25 Sep 2005 06:16:12 -0400 From: "Welitz Jan" To: "Kanatova Assel" Subject: Re[4]: Date: Sun, 25 Sep 2005 10:09:04 +0000 X-SA-Do-Not-Rej: Yes Message-ID: <72db01c5c1b9$0f73c101$9cff0444@sunpoint.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_40CE_1F627A89.B53D40CE" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Antivirus: avast! (VPS 0538-7, 2005-09-23), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. ------=_NextPart_000_40CE_1F627A89.B53D40CE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Best choice for those who have it! SPUR-m [Sperm pills]: http://giddies.com/ ------=_NextPart_000_40CE_1F627A89.B53D40CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Best choice for those who have it!
 
SPUR-m [Sperm pills]: http://giddies.com/
------=_NextPart_000_40CE_1F627A89.B53D40CE-- From capwap-admin@frascone.com Mon Sep 26 00:35:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJki2-0001PI-5l for capwap-archive@megatron.ietf.org; Mon, 26 Sep 2005 00:35:39 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19842 for ; Mon, 26 Sep 2005 00:35:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1AFAF20484; Mon, 26 Sep 2005 00:35:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53CFB203E9; Mon, 26 Sep 2005 00:35:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2CCB203E9 for ; Mon, 26 Sep 2005 00:34:05 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id BBA7F2038E for ; Mon, 26 Sep 2005 00:34:03 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j8Q4RCiV029716; Sun, 25 Sep 2005 21:27:17 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509260427.j8Q4RCiV029716@homebrew.trpz.com> To: "James Kempf" Cc: Dorothy.Gellert@nokia.com, capwap@frascone.com, mmani@avaya.com, bwijnen@lucent.com, david.kessens@nokia.com Subject: Re: [Capwap] CAPWAP evaluation draft complete In-Reply-To: Your message of "Thu, 22 Sep 2005 10:56:09 PDT." <090201c5bf9e$e9903fd0$196115ac@dcml.docomolabsusa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29714.1127708832.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sun, 25 Sep 2005 21:27:12 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) James, I'm curious why you say that the recommendations of the evaluation team are "nontechnical". Many of them seem quite technical to me. - change the security and authentication protocol to be DTLS - add a tunneling mode for local MAC - get rid of the extraneous L2 encapsulation option - use a different tunneling protocol, like GRE. It should be noted that all of those are already part of SLAPP. Now I understand that the 4 member evaluation team made a decision that cannot be changed by the WG and that the WG just has to accept it but it seems to me that it would be easier to start with SLAPP as a foundation and to change a few messages here and there to address whatever shortcomings were perceived instead of taking LWAPP and replacing its foundation-- its security components, how it does tunneling, and its tunneling options-- with SLAPP's. Dan. On Thu, 22 Sep 2005 10:56:09 PDT you wrote > Dorothy and Mani, > > After reading the evaluation document, I support the recommendation of the > evaluation team. I hope the WG will be able to resolve the lingering > nontechnical issues fairly quickly and move forward with completing the > CAPWAP protocol based on the evaluation document's recommendations. > > I would also suggest that someone with good writing skills do an editing > pass through the evaluation document before it is submitted to the IESG, > since I noticed numerous typos and minor grammatical errors. > > jak > > ----- Original Message ----- > From: > To: > Cc: ; ; ; > > Sent: Wednesday, September 21, 2005 6:34 PM > Subject: [Capwap] CAPWAP evaluation draft complete > > > > After much hard work, the evaluation team has completed the CAPWAP > evaluation draft. Its is available for review at: > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and > also in the internet drafts directory. > > The evaluation team concluded that LWAPP is the most complete proposal > and should be used as the basis for CAPWAP protocol moving forward. In > addition, a number of recommendations were made which the evaluation > team believed should be addressed by the working group. > > Over the next 2 weeks the evaluation team will address clarification > questions on the WG list. The recommendation provided by the > evaluation team will not change, as this was intended to be an > independent activity supported by the WG. This is essentially a WGLC > on the evaluation draft. Please submit any clarification question to > the list by Friday, September 30th. > > The next step will be to come to an agreement on the WG list to decide > to accept the recommended protocol. Once we have established consensus, > we can further discuss the additional recommendations presented in the > draft. > > We would like to thank the evaluation team on its thorough work and a > job well done. > > Regards, > Dorothy and Mani > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 26 02:14:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJmFo-0005U7-Ts for capwap-archive@megatron.ietf.org; Mon, 26 Sep 2005 02:14:23 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04016 for ; Mon, 26 Sep 2005 02:14:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CBB3D204F5; Mon, 26 Sep 2005 02:14:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9A5D20471; Mon, 26 Sep 2005 02:14:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D99520471 for ; Mon, 26 Sep 2005 02:13:45 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id 7457A203E9 for ; Mon, 26 Sep 2005 02:13:42 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8Q6Dc7Z024251; Mon, 26 Sep 2005 01:13:40 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Sep 2005 08:13:37 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508234632@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Dan Harkins Cc: "Capwap (E-mail)" , david.kessens@nokia.com Subject: RE: [Capwap] CAPWAP evaluation draft complete MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 26 Sep 2005 08:13:35 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) [dropped WG chairs, and James, they are on the mailing list. and so am I]. W.r.t. > Now I understand that the 4 member evaluation team made a decision The evaluation team made a "decision" if you like for itself, but they reported that decision as a RECOMMENDATION to the WG. > that cannot be changed by the WG and that the WG just has to accept it The WG CAN accpt it (instead of HAS TO accept it). After all, it is a RECOMMENDATION. Pls do not put words in the mouth of the evaluation team or the chairs. I do not believe any of them has stated that the WG HAS TO accept anything. So James has stated that he supports the recommendation of the team. You seem to not support that. So what do the other WG members think and opine? Bert > but it seems to me that it would be easier to start with SLAPP as > a foundation and to change a few messages here and there to address > whatever shortcomings were perceived instead of taking LWAPP and > replacing its foundation-- its security components, how it does > tunneling, and its tunneling options-- with SLAPP's. > > Dan. > > On Thu, 22 Sep 2005 10:56:09 PDT you wrote > > Dorothy and Mani, > > > > After reading the evaluation document, I support the > recommendation of the > > evaluation team. I hope the WG will be able to resolve the > lingering > > nontechnical issues fairly quickly and move forward with > completing the > > CAPWAP protocol based on the evaluation document's recommendations. > > > > I would also suggest that someone with good writing skills > do an editing > > pass through the evaluation document before it is submitted > to the IESG, > > since I noticed numerous typos and minor grammatical errors. > > > > jak > > > > ----- Original Message ----- > > From: > > To: > > Cc: ; ; > ; > > > > Sent: Wednesday, September 21, 2005 6:34 PM > > Subject: [Capwap] CAPWAP evaluation draft complete > > > > > > > > After much hard work, the evaluation team has completed the CAPWAP > > evaluation draft. Its is available for review at: > > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and > also in the internet drafts directory. > > The evaluation team concluded that LWAPP is the most complete proposal > and should be used as the basis for CAPWAP protocol moving forward. In > addition, a number of recommendations were made which the evaluation > team believed should be addressed by the working group. > > Over the next 2 weeks the evaluation team will address clarification > questions on the WG list. The recommendation provided by the > evaluation team will not change, as this was intended to be an > independent activity supported by the WG. This is essentially a WGLC > on the evaluation draft. Please submit any clarification question to > the list by Friday, September 30th. > > The next step will be to come to an agreement on the WG list to decide > to accept the recommended protocol. Once we have established consensus, > we can further discuss the additional recommendations presented in the > draft. > > We would like to thank the evaluation team on its thorough work and a > job well done. > > Regards, > Dorothy and Mani > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 26 10:22:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJtsA-0000mv-CH for capwap-archive@megatron.ietf.org; Mon, 26 Sep 2005 10:22:26 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00456 for ; Mon, 26 Sep 2005 10:22:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58FBA20512; Mon, 26 Sep 2005 10:22:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 428CE2050D; Mon, 26 Sep 2005 10:22:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 94F162050D for ; Mon, 26 Sep 2005 10:21:21 -0400 (EDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 71A072050A for ; Mon, 26 Sep 2005 10:21:18 -0400 (EDT) Received: from laffytaffy.cs.umd.edu (laffytaffy.cs.umd.edu [128.8.129.74]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j8QEES1q001001 for ; Mon, 26 Sep 2005 10:14:29 -0400 (EDT) From: "T. Charles Clancy" To: capwap@frascone.com Subject: RE: [Capwap] CAPWAP evaluation draft complete In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508234632@nl0006exch001u.nl.lucent.com> Message-ID: References: <7D5D48D2CAA3D84C813F5B154F43B15508234632@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 26 Sep 2005 10:14:28 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Mon, 26 Sep 2005, Wijnen, Bert (Bert) wrote: > The evaluation team made a "decision" if you like for itself, but they > reported that decision as a RECOMMENDATION to the WG. Well if we don't take it as more than a RECOMMENDATION, I wonder what the point of an evaluation team was. > So James has stated that he supports the recommendation of the team. You > seem to not support that. So what do the other WG members think and > opine? I support the recommendation. I agree with the idea of trying to reuse more standarized protocols within LWAPP, for example some sort of TLS-based authentication. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 26 12:19:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJvh9-0004Wh-Nk for capwap-archive@megatron.ietf.org; Mon, 26 Sep 2005 12:19:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22079 for ; Mon, 26 Sep 2005 12:19:08 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4703D20512; Mon, 26 Sep 2005 12:19:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFF702050D; Mon, 26 Sep 2005 12:19:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3ECF92050D for ; Mon, 26 Sep 2005 12:18:15 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 52D2220263 for ; Mon, 26 Sep 2005 12:18:12 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8QG4cU6019410 for ; Mon, 26 Sep 2005 12:04:39 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8QG4MU6018987 for ; Mon, 26 Sep 2005 12:04:23 -0400 (EDT) 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] CAPWAP evaluation draft complete Message-ID: Thread-Topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcXCpchddutblilAQ7aQgE4QD4kVnwADNiYg From: "Mani, Mahalingam (Mahalingam)" To: "T. Charles Clancy" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 26 Sep 2005 10:17:47 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Charles, Evaluation team acts on behalf of (and essentially represents a task-force of) the WG. This is a team picked out of the call-for-volunteers and agreed to by the WG. In spirit of above - it is more than a recommendation: expected to represent the collective assessment of the WG. The evaluation team has termed their conclusions as recommendations. The WG has to ratify the recommendations - given the consensus-based approach of IETF - confirming the WG is in sync with the conclusions drawn by the evaluation team that did the focused work.=20 -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of T. Charles Clancy Sent: Monday, September 26, 2005 7:14 AM To: capwap@frascone.com Subject: RE: [Capwap] CAPWAP evaluation draft complete On Mon, 26 Sep 2005, Wijnen, Bert (Bert) wrote: > The evaluation team made a "decision" if you like for itself, but they > reported that decision as a RECOMMENDATION to the WG. Well if we don't take it as more than a RECOMMENDATION, I wonder what the=20 point of an evaluation team was. > So James has stated that he supports the recommendation of the team. You=20 > seem to not support that. So what do the other WG members think and=20 > opine? I support the recommendation. I agree with the idea of trying to reuse=20 more standarized protocols within LWAPP, for example some sort of=20 TLS-based authentication. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 26 12:22:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJvk5-00066g-8S for capwap-archive@megatron.ietf.org; Mon, 26 Sep 2005 12:22:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22242 for ; Mon, 26 Sep 2005 12:22:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 952E420518; Mon, 26 Sep 2005 12:22:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A943E20510; Mon, 26 Sep 2005 12:22:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B282720510 for ; Mon, 26 Sep 2005 12:21:39 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 956B62050D for ; Mon, 26 Sep 2005 12:21:36 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j8QGFCIE031522; Mon, 26 Sep 2005 09:15:16 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509261615.j8QGFCIE031522@homebrew.trpz.com> To: "Wijnen, Bert (Bert)" Cc: "Capwap (E-mail)" , david.kessens@nokia.com Subject: Re: [Capwap] CAPWAP evaluation draft complete In-Reply-To: Your message of "Mon, 26 Sep 2005 08:13:35 +0200." <7D5D48D2CAA3D84C813F5B154F43B15508234632@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31520.1127751312.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 26 Sep 2005 09:15:12 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Bert, The way I understand Dorothy's announcment is that the RECOMMENDATION cannot be changed by the working group. Right now it's WGLC on their draft and they're to "address clarification questions on the WG list". Yes, we can do a wholesale rejection of the draft itself (and then it's back to square one) but we cannot change their recommendation. It is their recommendation that we must accept as is. This is a non-negotiable decision (err, RECOMMENDATION) and we're being asked to take it or leave it. My statement was not one of supporting or rejecting their recommendation it was pointing out that it's easier to add messages or remove messages from any of the protocols than it is to change the tunneling and security components of them. It would've been easier to start with SLAPP and add the messages that it lacked, and therefore not "most complete", then to start with LWAPP and replace 4 parts of its foundation with SLAPP's. I understand the evaluation and how they put LWAPP ahead of SLAPP but given that none of the proposals are completely satisfactory I don't understand why they chose the route they did. They obviously liked the security of SLAPP, its flexibility in tunnelling options, and how it does tunnelling. So why not start with the base you like and add the toppings instead of starting with the toppings and change the base? Heck, adding a control type in 4.5.1.8 of SLAPP for "LWAPP messaging" would make this a cut-and-paste exercise! You get the security you want, the tunnelling options you want, the way to tunnel you want, and the "most complete" messaging you want. As to your question on whether I support or reject their recommendation I guess I'd have to.........reject it on the grounds that a starting point along the lines of my observation above would've been easier to work with. Dan. On Mon, 26 Sep 2005 08:13:35 +0200 you wrote > [dropped WG chairs, and James, they are on the mailing list. > and so am I]. > > W.r.t. > > Now I understand that the 4 member evaluation team made a decision > > The evaluation team made a "decision" if you like for itself, > but they reported that decision as a RECOMMENDATION to the WG. > > > that cannot be changed by the WG and that the WG just has to accept it > > The WG CAN accpt it (instead of HAS TO accept it). > After all, it is a RECOMMENDATION. > > > Pls do not put words in the mouth of the evaluation team or the > chairs. I do not believe any of them has stated that the WG > HAS TO accept anything. > > So James has stated that he supports the recommendation of the > team. You seem to not support that. So what do the other WG members > think and opine? > > Bert > > but it seems to me that it would be easier to start with SLAPP as > > a foundation and to change a few messages here and there to address > > whatever shortcomings were perceived instead of taking LWAPP and > > replacing its foundation-- its security components, how it does > > tunneling, and its tunneling options-- with SLAPP's. > > > > Dan. > > > > On Thu, 22 Sep 2005 10:56:09 PDT you wrote > > > Dorothy and Mani, > > > > > > After reading the evaluation document, I support the > > recommendation of the > > > evaluation team. I hope the WG will be able to resolve the > > lingering > > > nontechnical issues fairly quickly and move forward with > > completing the > > > CAPWAP protocol based on the evaluation document's recommendations. > > > > > > I would also suggest that someone with good writing skills > > do an editing > > > pass through the evaluation document before it is submitted > > to the IESG, > > > since I noticed numerous typos and minor grammatical errors. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: > > > To: > > > Cc: ; ; > > ; > > > > > > Sent: Wednesday, September 21, 2005 6:34 PM > > > Subject: [Capwap] CAPWAP evaluation draft complete > > > > > > > > > > > > After much hard work, the evaluation team has completed the CAPWAP > > > evaluation draft. Its is available for review at: > > > > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and > > also in the internet drafts directory. > > > > The evaluation team concluded that LWAPP is the most complete proposal > > and should be used as the basis for CAPWAP protocol moving forward. In > > addition, a number of recommendations were made which the evaluation > > team believed should be addressed by the working group. > > > > Over the next 2 weeks the evaluation team will address clarification > > questions on the WG list. The recommendation provided by the > > evaluation team will not change, as this was intended to be an > > independent activity supported by the WG. This is essentially a WGLC > > on the evaluation draft. Please submit any clarification question to > > the list by Friday, September 30th. > > > > The next step will be to come to an agreement on the WG list to decide > > to accept the recommended protocol. Once we have established consensus, > > we can further discuss the additional recommendations presented in the > > draft. > > > > We would like to thank the evaluation team on its thorough work and a > > job well done. > > > > Regards, > > Dorothy and Mani > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 26 13:35:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJwsl-0002dK-QF for capwap-archive@megatron.ietf.org; Mon, 26 Sep 2005 13:35:17 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25389 for ; Mon, 26 Sep 2005 13:35:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89FD220513; Mon, 26 Sep 2005 13:35:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA82E2050D; Mon, 26 Sep 2005 13:35:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9BFD72050D for ; Mon, 26 Sep 2005 13:34:19 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 72A8D2050A for ; Mon, 26 Sep 2005 13:34:16 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8QHVVma024718 for ; Mon, 26 Sep 2005 13:31:32 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8QHVHma024327 for ; Mon, 26 Sep 2005 13:31:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C2C0.79276B80" Subject: RE: [Capwap] CAPWAP evaluation draft complete Message-ID: Thread-Topic: RE: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcXCwHgPTkkBbf+ZTYq/tHT1NFBQCg== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 26 Sep 2005 11:33:57 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C2C0.79276B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A further clarification note: =20 I had a question whether the 'ratification' leaves no choice for the WG. =20 Let me correct the interpretation: it is upto WG to ratify, i.e., accept the recommendations. =20 The WG consensus may be to choose not to ratify. =20 Regards, -mani > Charles, >=20 > Evaluation team acts on behalf of (and essentially represents a=20 > task-force of) the WG. This is a team picked out of the=20 > call-for-volunteers and agreed to by the WG. >=20 > In spirit of above - it is more than a recommendation: expected to=20 > represent the collective assessment of the WG. >=20 > The evaluation team has termed their conclusions as recommendations. >=20 > The WG has to ratify the recommendations - given the consensus-based=20 > approach of IETF - confirming the WG is in sync with the conclusions=20 > drawn by the evaluation team that did the focused work. >=20 > -mani > =3D=3D=3D=3D=3D=3D > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 > Behalf Of T. Charles Clancy > Sent: Monday, September 26, 2005 7:14 AM > To: capwap@frascone.com > Subject: RE: [Capwap] CAPWAP evaluation draft complete >=20 > On Mon, 26 Sep 2005, Wijnen, Bert (Bert) wrote: >=20 > > The evaluation team made a "decision" if you like for itself, but=20 > > they >=20 > > reported that decision as a RECOMMENDATION to the WG. >=20 > Well if we don't take it as more than a RECOMMENDATION, I wonder what=20 > the point of an evaluation team was. >=20 > > So James has stated that he supports the recommendation of the team. > You > > seem to not support that. So what do the other WG members think and=20 > > opine? >=20 > I support the recommendation. I agree with the idea of trying to=20 > reuse more standarized protocols within LWAPP, for example some sort=20 > of TLS-based authentication. >=20 > [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [=20 > computer science ]-----[ university of maryland | college park ]=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 =20 =20 =20 Regards, -mani =3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C5C2C0.79276B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A further clarification note:

 

I had a question whether the ‘ratification’ leaves no choice = for the WG.

 

Let me correct the interpretation: it is upto WG to ratify, i.e., = accept

the recommendations.

 

The WG consensus may be to choose not to = ratify.

 

Regards,

-mani

> Charles,

>

> Evaluation team acts on behalf of (and essentially represents a =

> task-force of) the WG. This is a team picked out of the =

> call-for-volunteers and agreed to by the = WG.

>

> In spirit of above - it is more than a recommendation: expected to =

> represent the collective assessment of the = WG.

>

> The evaluation team has termed their conclusions as = recommendations.

>

> The WG has to ratify the recommendations - given the consensus-based =

> approach of IETF - confirming the WG is in sync with the conclusions =

> drawn by the evaluation team that did the focused = work.

>

> -mani

> =3D=3D=3D=3D=3D=3D

> -----Original Message-----

> From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On

> Behalf Of T. Charles Clancy

> Sent: Monday, September 26, 2005 7:14 AM

> To: capwap@frascone.com

> Subject: RE: [Capwap] CAPWAP evaluation draft = complete

>

> On Mon, 26 Sep 2005, Wijnen, Bert (Bert) = wrote:

>

> > The evaluation team made a "decision" if you like for = itself, but

> > they

>

> > reported that decision as a RECOMMENDATION to the = WG.

>

> Well if we don't take it as more than a RECOMMENDATION, I wonder what =

> the point of an evaluation team was.

>

> > So James has stated that he supports the recommendation of the = team.

> You

> > seem to not support that. So what do the other WG members think and =

> > opine?

>

> I support the recommendation.  I agree with the idea of trying to =

> reuse more standarized protocols within LWAPP, for example some sort =

> of TLS-based authentication.

>

> [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [

> computer science ]-----[ university of maryland | college park ] =

> _______________________________________________<= /p>

> Capwap mailing list

> Capwap@frascone.com

> http://mail.fra= scone.com/mailman/listinfo/capwap

>

>

> _______________________________________________<= /p>

> Capwap mailing list

> Capwap@frascone.com

> http://mail.fra= scone.com/mailman/listinfo/capwap

>

 

 

 

Regards,

-mani

=3D=3D=3D=3D=3D=3D

 

------_=_NextPart_001_01C5C2C0.79276B80-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 26 16:34:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJzfy-0006rM-55 for capwap-archive@megatron.ietf.org; Mon, 26 Sep 2005 16:34:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07721 for ; Mon, 26 Sep 2005 16:34:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1B252051C; Mon, 26 Sep 2005 16:34:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D217F20516; Mon, 26 Sep 2005 16:34:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B9DEA20512 for ; Mon, 26 Sep 2005 16:33:19 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id C488820511 for ; Mon, 26 Sep 2005 16:33:17 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8QKXEZG011193; Mon, 26 Sep 2005 15:33:14 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Sep 2005 22:33:13 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508234A0C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Dan Harkins Cc: "Capwap (E-mail)" , david.kessens@nokia.com Subject: RE: [Capwap] CAPWAP evaluation draft complete MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 26 Sep 2005 22:33:05 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Inline, speaking as an individual > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com] > Sent: Monday, September 26, 2005 18:15 > To: Wijnen, Bert (Bert) > Cc: Capwap (E-mail); david.kessens@nokia.com > Subject: Re: [Capwap] CAPWAP evaluation draft complete > > > Bert, > > The way I understand Dorothy's announcment is that the RECOMMENDATION > cannot be changed by the working group. I think if the ET does a recommendation, then that is their reccommendation. If we get clarifications over the next week, and as a result of that the ET comes to a different conclusion, then the ET might change their recomendation, but it is still their recommendation. The WG can decide if they want to accpet or reject the recommendation. > Right now it's WGLC on their draft and they're to "address clarification > questions on the WG list". > My understanding is that if the doc is unclear that the WG gets a chance to ask for clarifications and that such may lead to changes in the document. The ET may or may not change their recoemmendation based on that discussion. In the end, it still is a recommendation from the ET, and it is then up to the WG to accept or reject such a recommendation. Maybe the WG decides that they want to pick up part of the recommendation but not all of it. That is a separate WG decision. Or at least that is how I look at it. > Yes, we can do a wholesale rejection of the draft itself > (and then it's > back to square one) but we cannot change their recommendation. It is > their recommendation that we must accept as is. I think there is a difference. - who are we (anyone) to change someone elses rfecommendation? It sounds as if you want to change someones opinion or conclusion after they have studied. You can try, but I do not think you can OVERRIDE their opinion (i.e recommendation) > This is a non-negotiable > decision (err, RECOMMENDATION) and we're being asked to take > it or leave it. > I think you/we have the option to - accept the recommendation as is - reject the recommendation as a whole - accept part of the recommendation and add other pieces In other words, the evaluation team has documented their findings and has documented their recommendation. The WG can decide what to do with the recommendation. > My statement was not one of supporting or rejecting their > recommendation > it was pointing out that it's easier to add messages or > remove messages > from any of the protocols than it is to change the tunneling > and security > components of them. It would've been easier to start with > SLAPP and add > the messages that it lacked, and therefore not "most > complete", then to > start with LWAPP and replace 4 parts of its foundation with SLAPP's. > So to me it sounds thatr you do not want to accept the recommendation and to me it sounds as if you have a different recommendation to the WG. And it seems you have some explanation as to why you think that your recommendation is better. The WG can look at that too and opine on your recommendation. > I understand the evaluation and how they put LWAPP ahead of > SLAPP but > given that none of the proposals are completely satisfactory I don't > understand why they chose the route they did. They obviously liked the > security of SLAPP, its flexibility in tunnelling options, and how it > does tunnelling. So why not start with the base you like and add the > toppings instead of starting with the toppings and change the base? > > Heck, adding a control type in 4.5.1.8 of SLAPP for "LWAPP > messaging" > would make this a cut-and-paste exercise! You get the > security you want, > the tunnelling options you want, the way to tunnel you want, and the > "most complete" messaging you want. > > As to your question on whether I support or reject their > recommendation > I guess I'd have to...... it!>...reject it on > the grounds that a starting point along the lines of my > observation above > would've been easier to work with. > I hope I answered this above Bert > Dan. > > On Mon, 26 Sep 2005 08:13:35 +0200 you wrote > > [dropped WG chairs, and James, they are on the mailing list. > > and so am I]. > > > > W.r.t. > > > Now I understand that the 4 member evaluation team made > a decision > > > > The evaluation team made a "decision" if you like for itself, > > but they reported that decision as a RECOMMENDATION to the WG. > > > > > that cannot be changed by the WG and that the WG just has > to accept it > > > > The WG CAN accpt it (instead of HAS TO accept it). > > After all, it is a RECOMMENDATION. > > > > > > Pls do not put words in the mouth of the evaluation team or the > > chairs. I do not believe any of them has stated that the WG > > HAS TO accept anything. > > > > So James has stated that he supports the recommendation of the > > team. You seem to not support that. So what do the other WG members > > think and opine? > > > > Bert > > > but it seems to me that it would be easier to start with SLAPP as > > > a foundation and to change a few messages here and there > to address > > > whatever shortcomings were perceived instead of taking LWAPP and > > > replacing its foundation-- its security components, how it does > > > tunneling, and its tunneling options-- with SLAPP's. > > > > > > Dan. > > > > > > On Thu, 22 Sep 2005 10:56:09 PDT you wrote > > > > Dorothy and Mani, > > > > > > > > After reading the evaluation document, I support the > > > recommendation of the > > > > evaluation team. I hope the WG will be able to resolve the > > > lingering > > > > nontechnical issues fairly quickly and move forward with > > > completing the > > > > CAPWAP protocol based on the evaluation document's > recommendations. > > > > > > > > I would also suggest that someone with good writing skills > > > do an editing > > > > pass through the evaluation document before it is submitted > > > to the IESG, > > > > since I noticed numerous typos and minor grammatical errors. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: > > > > Cc: ; ; > > > ; > > > > > > > > Sent: Wednesday, September 21, 2005 6:34 PM > > > > Subject: [Capwap] CAPWAP evaluation draft complete > > > > > > > > > > > > > > > > After much hard work, the evaluation team has completed > the CAPWAP > > > > evaluation draft. Its is available for review at: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and > > also in the internet drafts directory. > > > > The evaluation team concluded that LWAPP is the most complete proposal > > and should be used as the basis for CAPWAP protocol moving forward. In > > addition, a number of recommendations were made which the evaluation > > team believed should be addressed by the working group. > > > > Over the next 2 weeks the evaluation team will address clarification > > questions on the WG list. The recommendation provided by the > > evaluation team will not change, as this was intended to be an > > independent activity supported by the WG. This is essentially a WGLC > > on the evaluation draft. Please submit any clarification question to > > the list by Friday, September 30th. > > > > The next step will be to come to an agreement on the WG list to decide > > to accept the recommended protocol. Once we have established consensus, > > we can further discuss the additional recommendations presented in the > > draft. > > > > We would like to thank the evaluation team on its thorough work and a > > job well done. > > > > Regards, > > Dorothy and Mani > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 26 17:02:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK078-0004Ue-4t for capwap-archive@megatron.ietf.org; Mon, 26 Sep 2005 17:02:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09311 for ; Mon, 26 Sep 2005 17:02:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65BD72051F; Mon, 26 Sep 2005 17:02:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50B9320516; Mon, 26 Sep 2005 17:02:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B785620516 for ; Mon, 26 Sep 2005 17:01:37 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id A3D7B20511 for ; Mon, 26 Sep 2005 17:01:35 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8QL1Qx3001035; Mon, 26 Sep 2005 16:01:27 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Sep 2005 23:01:25 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508234A0E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "T. Charles Clancy" , capwap@frascone.com Subject: RE: [Capwap] CAPWAP evaluation draft complete MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 26 Sep 2005 23:01:23 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Inline > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of T. Charles Clancy > Sent: Monday, September 26, 2005 16:14 > To: capwap@frascone.com > Subject: RE: [Capwap] CAPWAP evaluation draft complete > > > On Mon, 26 Sep 2005, Wijnen, Bert (Bert) wrote: > > > The evaluation team made a "decision" if you like for > itself, but they > > reported that decision as a RECOMMENDATION to the WG. > > Well if we don't take it as more than a RECOMMENDATION, I > wonder what the point of an evaluation team was. > I believe the value was en is that we had a dedicated team of people who have meticoulously studied the objectives and the submission and who have after that documented their findings precisely and at then end even gave a recommendation. That is a very useful piece of input for the WG based on which they can try to come to a decision as what to do. This in addition to any other input (like your own evaluation etc). Bert _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Sep 26 20:32:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK3OH-0001CS-5D for capwap-archive@megatron.ietf.org; Mon, 26 Sep 2005 20:32:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21033 for ; Mon, 26 Sep 2005 20:32:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B620B20428; Mon, 26 Sep 2005 20:32:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF1FC1FE11; Mon, 26 Sep 2005 20:32:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C06461FE11 for ; Mon, 26 Sep 2005 20:31:35 -0400 (EDT) Received: from oz.twisted.net (oz.twisted.net [69.211.34.241]) by mail.frascone.com (Postfix) with ESMTP id C1DA01FD6C for ; Mon, 26 Sep 2005 20:31:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by oz.twisted.net (Postfix) with ESMTP id 3837A599CA1 for ; Mon, 26 Sep 2005 19:43:27 -0500 (CDT) Received: from oz.twisted.net ([127.0.0.1]) by localhost (oz.twisted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51249-01 for ; Mon, 26 Sep 2005 19:43:26 -0500 (CDT) Received: from noodle (sindrome.twisted.net [172.16.0.5]) by oz.twisted.net (Postfix) with ESMTP id 2B3AB599C9F for ; Mon, 26 Sep 2005 19:43:24 -0500 (CDT) Reply-To: From: "Troy Dixler" To: Subject: RE: [Capwap] CAPWAP evaluation draft complete MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXC30ArKgYOgSkCQq6cJhzue2e0VgAGvE6A In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508234A0E@nl0006exch001u.nl.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Message-Id: <20050927004324.2B3AB599C9F@oz.twisted.net> X-Virus-Scanned: by amavisd-new at twisted.net X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 26 Sep 2005 19:29:57 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I guess I'm not following the logic behind the recommendation. It seems to me that rather than the group focusing in on what draft, they should be focusing in on what attributes they want in the CAPWAP protocol. There are clearly pieces of both base protocols that bring value to the working group. In the end the best pieces will become the basis we work from to become a standard. To pick a "side" when clearly there were attributes that were not within LWAPP just stirs up politics. Why not revise the draft to state the clear attributes and recommendations that the protocol should contain and not start with either base draft but start it fresh and call it by its rightful name CAPWAP. -Troy > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Wijnen, Bert (Bert) > Sent: Monday, September 26, 2005 4:01 PM > To: T. Charles Clancy; capwap@frascone.com > Subject: RE: [Capwap] CAPWAP evaluation draft complete > > Inline > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of T. Charles Clancy > > Sent: Monday, September 26, 2005 16:14 > > To: capwap@frascone.com > > Subject: RE: [Capwap] CAPWAP evaluation draft complete > > > > > > On Mon, 26 Sep 2005, Wijnen, Bert (Bert) wrote: > > > > > The evaluation team made a "decision" if you like for > > itself, but they > > > reported that decision as a RECOMMENDATION to the WG. > > > > Well if we don't take it as more than a RECOMMENDATION, I > > wonder what the point of an evaluation team was. > > > > I believe the value was en is that we had a dedicated team of people > who have meticoulously studied the objectives and the submission and > who have after that documented their findings precisely and at > then end even gave a recommendation. > > That is a very useful piece of input for the WG based on which they > can try to come to a decision as what to do. This in addition to any > other input (like your own evaluation etc). > > Bert > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 03:20:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK9l8-0001TW-S6 for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 03:20:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19889 for ; Tue, 27 Sep 2005 03:20:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1E9920388; Tue, 27 Sep 2005 03:20:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CD081FD6C; Tue, 27 Sep 2005 03:20:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65BF31FD6C for ; Tue, 27 Sep 2005 03:19:11 -0400 (EDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by mail.frascone.com (Postfix) with ESMTP id 14CEF1FC21 for ; Tue, 27 Sep 2005 03:19:08 -0400 (EDT) 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 j8R7J6II022906 for ; Tue, 27 Sep 2005 16:19:06 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j8R7J6304332 for ; Tue, 27 Sep 2005 16:19:06 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id j8R7J5D12924 for ; Tue, 27 Sep 2005 16:19:05 +0900 (JST) 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 Message-ID: <5F09D220B62F79418461A978CA0921BD672F3A@pslexc01.psl.local> Thread-topic: CAPWAP Objectives - Logical Groups Thread-Index: AcXDM2S3v0pKnvTaTVKsliazai7tqQ== From: "Saravanan Govindan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] CAPWAP Objectives - Logical Groups Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 15:16:42 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable All, Regarding the Objectives document, it was last suggested that the Protocol Requirement for the Logical Groups objective (Section 5.1.1) be updated to reflect needs for local-MAC architectures.=20 The current requirement is; "The CAPWAP protocol MUST be capable of controlling and managing physical WTPs in terms of logical groups including BSSID-based groups." Then it was suggested by Pat to extend with; "The CAPWAP protocol MUST be capable of controlling and managing physical WTPs in terms of logical groups including BSSID-based groups. For non-tunneled mode, the protocols MUST also provide the provisions=20 to configure the associated VLAN (or subnet) which is to be used by=20 the WTP in bridging traffic for the logical group." Since the Objectives draft does not define "non-tunneled mode", I'm thinking of rewording for a more clear requirement. Consider the following; "The CAPWAP protocol MUST be capable of controlling and managing physical WTPs in terms of logical groups including BSSID-based groups. For all operating modes, including those in which the WTP performs local bridging and those in which the AC performs centralized bridging, the protocol MUST provide provisions for configuring logical groups across the AC-WTP interface." =20 I look forward to any further suggestions on this.=20 Saravanan =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 03:48:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKACE-0007QP-3i for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 03:48:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21265 for ; Tue, 27 Sep 2005 03:48:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34C412048D; Tue, 27 Sep 2005 03:48:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4678A1FE0E; Tue, 27 Sep 2005 03:48:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DCC981FE0E for ; Tue, 27 Sep 2005 03:47:47 -0400 (EDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by mail.frascone.com (Postfix) with ESMTP id ACBCC1FC21 for ; Tue, 27 Sep 2005 03:47:45 -0400 (EDT) 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 j8R7lhII026179; Tue, 27 Sep 2005 16:47:43 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j8R7lir21390; Tue, 27 Sep 2005 16:47:44 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id j8R7lg109872; Tue, 27 Sep 2005 16:47:42 +0900 (JST) 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] Evaluation Team draft submitted Message-ID: <5F09D220B62F79418461A978CA0921BD672F59@pslexc01.psl.local> Thread-topic: [Capwap] Evaluation Team draft submitted Thread-Index: AcW5QiPIhf3nEv8mS9+Ud/GDm2fnBgJ8iwHA From: "Saravanan Govindan" To: "Darren Loher" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 15:45:18 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Darren, I think the CAPWAP Evaluation draft provides a great deal of insight in to the candidate protocols and I appreciate the evaulation team's efforts in providing it. =20 Regarding WiCoP and the IEEE 802.11i Considerations objective, (Section 6.10), I was hoping to get clarification on the rating. Section 6.5.6 of the WiCoP specifications details how IEEE 802.11i 4-way handshake is managed.=20 Also, there was a recent post on how sequence counter values are managed for the 802.11i group key handshake and this is also covered in the WiCoP specifications. =20 Thanks Saravanan=20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Wednesday, September 14, 2005 11:37 PM To: capwap@frascone.com Subject: [Capwap] Evaluation Team draft submitted =09 =09 The evaluation team draft was submitted last night to internet-drafts@ietf.org. It should appear in the Internet Drafts soon as: =20 draft-ietf-capwap-eval-00.txt =20 =20 -- Darren Loher Roving Planet =20 http://www.rovingplanet.com +1.303.996.7578 =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 06:06:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKCLk-0004RP-K7 for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 06:06:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26840 for ; Tue, 27 Sep 2005 06:06:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3741920428; Tue, 27 Sep 2005 06:06:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20E0E1FE1B; Tue, 27 Sep 2005 06:06:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 283F01FE1B for ; Tue, 27 Sep 2005 06:05:26 -0400 (EDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by mail.frascone.com (Postfix) with ESMTP id 9AFF91FC21 for ; Tue, 27 Sep 2005 06:05:23 -0400 (EDT) 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 j8RA5Ld2008988; Tue, 27 Sep 2005 19:05:21 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j8RA5Mr24906; Tue, 27 Sep 2005 19:05:22 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id j8RA5MN01232; Tue, 27 Sep 2005 19:05:22 +0900 (JST) 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] CAPWAP evaluation draft complete Message-ID: <5F09D220B62F79418461A978CA0921BD672FDA@pslexc01.psl.local> Thread-topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcXC30ArKgYOgSkCQq6cJhzue2e0VgAGvE6AAA5TQbA= From: "Saravanan Govindan" To: , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 18:02:57 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Troy, I like your suggestion of highlighting protocol attributes. I think doing so would help in developing a solid CAPWAP protocol.=20 The CAPWAP Comparative Analysis document seems to be in line with this. It highlights specific mechanisms in the candidate protocols that best address the requirements.=20 The WG can consider incorporating some of the specifics of the Comparative Analysis in the Evaluation draft.=20 Saravanan > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Troy Dixler > Sent: Tuesday, September 27, 2005 8:30 AM > To: capwap@frascone.com > Subject: RE: [Capwap] CAPWAP evaluation draft complete >=20 > I guess I'm not following the logic behind the=20 > recommendation. It seems to me that rather than the group=20 > focusing in on what draft, they should be focusing in on what=20 > attributes they want in the CAPWAP protocol. There are=20 > clearly pieces of both base protocols that bring value to the=20 > working group. > In the end the best pieces will become the basis we work from=20 > to become a standard. >=20 > To pick a "side" when clearly there were attributes that were=20 > not within LWAPP just stirs up politics. >=20 > Why not revise the draft to state the clear attributes and=20 > recommendations that the protocol should contain and not=20 > start with either base draft but start it fresh and call it=20 > by its rightful name CAPWAP. >=20 > -Troy >=20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > > Behalf Of Wijnen, Bert (Bert) > > Sent: Monday, September 26, 2005 4:01 PM > > To: T. Charles Clancy; capwap@frascone.com > > Subject: RE: [Capwap] CAPWAP evaluation draft complete > >=20 > > Inline > >=20 > > > -----Original Message----- > > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com]On > > > Behalf Of T. Charles Clancy > > > Sent: Monday, September 26, 2005 16:14 > > > To: capwap@frascone.com > > > Subject: RE: [Capwap] CAPWAP evaluation draft complete > > > > > > > > > On Mon, 26 Sep 2005, Wijnen, Bert (Bert) wrote: > > > > > > > The evaluation team made a "decision" if you like for > > > itself, but they > > > > reported that decision as a RECOMMENDATION to the WG. > > > > > > Well if we don't take it as more than a RECOMMENDATION, I wonder=20 > > > what the point of an evaluation team was. > > > > >=20 > > I believe the value was en is that we had a dedicated team=20 > of people=20 > > who have meticoulously studied the objectives and the=20 > submission and=20 > > who have after that documented their findings precisely and at then=20 > > end even gave a recommendation. > >=20 > > That is a very useful piece of input for the WG based on which they=20 > > can try to come to a decision as what to do. This in=20 > addition to any=20 > > other input (like your own evaluation etc). > >=20 > > Bert > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 09:35:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKFc1-0001Jb-50 for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 09:35:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07793 for ; Tue, 27 Sep 2005 09:35:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A53BB20506; Tue, 27 Sep 2005 09:35:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D649120428; Tue, 27 Sep 2005 09:35:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6C0220428 for ; Tue, 27 Sep 2005 09:34:56 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id A76D420230 for ; Tue, 27 Sep 2005 09:34:53 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 27 Sep 2005 06:34:53 -0700 X-IronPort-AV: i="3.97,150,1125903600"; d="scan'208"; a="662199238:sNHT28163512" 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 j8RDYm4V012911; Tue, 27 Sep 2005 06:34:48 -0700 (PDT) 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); Tue, 27 Sep 2005 06:34:50 -0700 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] CAPWAP evaluation draft complete Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8AFFD@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcXC30ArKgYOgSkCQq6cJhzue2e0VgAGvE6AABt0mtA= From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 27 Sep 2005 13:34:50.0408 (UTC) FILETIME=[3C357A80:01C5C368] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 06:34:48 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable > Why not revise the draft to state the clear attributes and=20 > recommendations that the protocol should contain and not=20 > start with either base draft but start it fresh and call it=20 > by its rightful name CAPWAP. I don't think the name is germane. There is no hard and fast rule that a WG's name must match the protocol (or the other way around). For instance, AAA is working on Diameter. There are plenty of other examples in the IETF. That said, I believe that the motivation for starting with a base draft is to get to the finish line quicker than starting from a blank piece of paper. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 09:37:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKFdw-0001WK-2O for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 09:37:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07987 for ; Tue, 27 Sep 2005 09:37:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 764F720512; Tue, 27 Sep 2005 09:37:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC79A20428; Tue, 27 Sep 2005 09:37:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D42762043D for ; Tue, 27 Sep 2005 09:36:26 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 0D3FC20230 for ; Tue, 27 Sep 2005 09:36:24 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 27 Sep 2005 06:36:24 -0700 X-IronPort-AV: i="3.97,150,1125903600"; d="scan'208"; a="345910142:sNHT31111616" 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 j8RDa34j013438; Tue, 27 Sep 2005 06:36:21 -0700 (PDT) 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, 27 Sep 2005 06:36:18 -0700 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] CAPWAP Objectives - Logical Groups Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8AFFE@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] CAPWAP Objectives - Logical Groups Thread-Index: AcXDM2S3v0pKnvTaTVKsliazai7tqQANPh2g From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , X-OriginalArrivalTime: 27 Sep 2005 13:36:18.0062 (UTC) FILETIME=[70746AE0:01C5C368] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 06:36:16 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable You say: > For all operating modes, including those in which the WTP performs local bridging and=20 > those in which the AC performs centralized bridging, the protocol MUST provide provisions=20 > for configuring logical groups across > the AC-WTP interface. But what does the AC-WTP interface mean when data is locally bridged?=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > Sent: Tuesday, September 27, 2005 12:17 AM > To: capwap@frascone.com > Subject: [Capwap] CAPWAP Objectives - Logical Groups >=20 > All, >=20 > Regarding the Objectives document, it was last suggested that=20 > the Protocol Requirement for the Logical Groups objective=20 > (Section 5.1.1) be updated to reflect needs for local-MAC=20 > architectures.=20 >=20 > The current requirement is; >=20 > "The CAPWAP protocol MUST be capable of controlling and=20 > managing physical WTPs in terms of logical groups including=20 > BSSID-based groups." >=20 >=20 >=20 > Then it was suggested by Pat to extend with; >=20 > "The CAPWAP protocol MUST be capable of controlling and=20 > managing physical WTPs in terms of logical groups including=20 > BSSID-based groups. >=20 > For non-tunneled mode, the protocols MUST also provide the=20 > provisions to configure the associated VLAN (or subnet) which=20 > is to be used by the WTP in bridging traffic for the logical group." >=20 >=20 >=20 > Since the Objectives draft does not define "non-tunneled=20 > mode", I'm thinking of rewording for a more clear=20 > requirement. Consider the following; >=20 > "The CAPWAP protocol MUST be capable of controlling and=20 > managing physical WTPs in terms of logical groups including=20 > BSSID-based groups. >=20 > For all operating modes, including those in which the WTP=20 > performs local bridging and those in which the AC performs=20 > centralized bridging, the protocol MUST provide provisions=20 > for configuring logical groups across > the AC-WTP interface." =20 >=20 > I look forward to any further suggestions on this.=20 >=20 > Saravanan =20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 12:12:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKI42-0007Oq-7f for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 12:12:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23389 for ; Tue, 27 Sep 2005 12:12:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3BAD20523; Tue, 27 Sep 2005 12:12:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D75D20506; Tue, 27 Sep 2005 12:12:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E906120506 for ; Tue, 27 Sep 2005 12:11:06 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id DB0D620230 for ; Tue, 27 Sep 2005 12:11:04 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 09:15:12 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 09:10:33 -0700 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] CAPWAP evaluation draft complete Message-ID: Thread-Topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcXC30ArKgYOgSkCQq6cJhzue2e0VgAGvE6AAB+1LSA= From: "Darren Loher" To: , X-OriginalArrivalTime: 27 Sep 2005 16:10:33.0093 (UTC) FILETIME=[FCE21350:01C5C37D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 09:10:21 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The evaluation team focused on the WG objectives for evaluating the proposals. We elected to choose the base protocol which most fully implemented the objectives. We chose a base protocol as a compromise to help speed the delivery of a standard. The evaluation team believes that LWAPP meets the objectives as defined better than any of the other protocols. That is the basis for choosing LWAPP as a base protocol. Hopefully the WG can first consider if LWAPP is a suitable base protocol. Obviously choosing a base protocol has a lot to do with whatever changes we as a group think we're going to need to make to this base. But if we can choose a base protocol, we will make a huge leap forward in getting a real, working CAPWAP protocol defined. The team thought this is the best approach for us to make progress as a working group. We did consider an approach of a new proposal with the best features of all the good and interesting capabilities presented. However, as a team we agreed this would be akin to "starting over" and would likely extend the standards process by another year, if not longer. I am not in favor of this, but it is up to working group consensus to decide if a delay like that is desirable. =20 The additional recommendations are issues that the evaluation team would like the working group to consider. We did not believe they are required to meet the official WG objectives. However we strongly believed that LWAPP would be a much better protocol if the "high priority" recommendations were implemented in some way within LWAPP. It's up to the working group at large to decide if these recommendations are important enough to implement. =20 -Darren > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Troy Dixler > Sent: Monday, September 26, 2005 6:30 PM > To: capwap@frascone.com > Subject: RE: [Capwap] CAPWAP evaluation draft complete >=20 > I guess I'm not following the logic behind the recommendation. It seems > to > me that rather than the group focusing in on what draft, they should be > focusing in on what attributes they want in the CAPWAP protocol. There > are > clearly pieces of both base protocols that bring value to the working > group. > In the end the best pieces will become the basis we work from to become a > standard. >=20 > To pick a "side" when clearly there were attributes that were not within > LWAPP just stirs up politics. >=20 > Why not revise the draft to state the clear attributes and recommendations > that the protocol should contain and not start with either base draft but > start it fresh and call it by its rightful name CAPWAP. >=20 > -Troy >=20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Wijnen, Bert (Bert) > > Sent: Monday, September 26, 2005 4:01 PM > > To: T. Charles Clancy; capwap@frascone.com > > Subject: RE: [Capwap] CAPWAP evaluation draft complete > > > > Inline > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > > Behalf Of T. Charles Clancy > > > Sent: Monday, September 26, 2005 16:14 > > > To: capwap@frascone.com > > > Subject: RE: [Capwap] CAPWAP evaluation draft complete > > > > > > > > > On Mon, 26 Sep 2005, Wijnen, Bert (Bert) wrote: > > > > > > > The evaluation team made a "decision" if you like for > > > itself, but they > > > > reported that decision as a RECOMMENDATION to the WG. > > > > > > Well if we don't take it as more than a RECOMMENDATION, I > > > wonder what the point of an evaluation team was. > > > > > > > I believe the value was en is that we had a dedicated team of people > > who have meticoulously studied the objectives and the submission and > > who have after that documented their findings precisely and at > > then end even gave a recommendation. > > > > That is a very useful piece of input for the WG based on which they > > can try to come to a decision as what to do. This in addition to any > > other input (like your own evaluation etc). > > > > Bert > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 12:24:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKIFa-0004pm-JK for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 12:24:14 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24112 for ; Tue, 27 Sep 2005 12:24:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD78720528; Tue, 27 Sep 2005 12:24:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A808E20506; Tue, 27 Sep 2005 12:24:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7031620506 for ; Tue, 27 Sep 2005 12:23:50 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 3904F20230 for ; Tue, 27 Sep 2005 12:23:47 -0400 (EDT) Message-ID: <036401c5c37f$d5914ee0$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Dan Harkins" Cc: , , , , References: <200509260427.j8Q4RCiV029716@homebrew.trpz.com> Subject: Re: [Capwap] CAPWAP evaluation draft complete MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 09:23:46 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dan, Perhaps my email wasn't clear. The recommendations are technical, and I support them. The nontechnical issues I was referring to are the ones that have been discussed on the email list, which you've raised. jak ----- Original Message ----- From: "Dan Harkins" To: "James Kempf" Cc: ; ; ; ; Sent: Sunday, September 25, 2005 9:27 PM Subject: Re: [Capwap] CAPWAP evaluation draft complete > James, > > I'm curious why you say that the recommendations of the evaluation > team are "nontechnical". Many of them seem quite technical to me. > > - change the security and authentication protocol to be DTLS > - add a tunneling mode for local MAC > - get rid of the extraneous L2 encapsulation option > - use a different tunneling protocol, like GRE. > > It should be noted that all of those are already part of SLAPP. > > Now I understand that the 4 member evaluation team made a decision > that cannot be changed by the WG and that the WG just has to accept > it but it seems to me that it would be easier to start with SLAPP as > a foundation and to change a few messages here and there to address > whatever shortcomings were perceived instead of taking LWAPP and > replacing its foundation-- its security components, how it does > tunneling, and its tunneling options-- with SLAPP's. > > Dan. > > On Thu, 22 Sep 2005 10:56:09 PDT you wrote >> Dorothy and Mani, >> >> After reading the evaluation document, I support the recommendation of >> the >> evaluation team. I hope the WG will be able to resolve the lingering >> nontechnical issues fairly quickly and move forward with completing the >> CAPWAP protocol based on the evaluation document's recommendations. >> >> I would also suggest that someone with good writing skills do an editing >> pass through the evaluation document before it is submitted to the IESG, >> since I noticed numerous typos and minor grammatical errors. >> >> jak >> >> ----- Original Message ----- >> From: >> To: >> Cc: ; ; ; >> >> Sent: Wednesday, September 21, 2005 6:34 PM >> Subject: [Capwap] CAPWAP evaluation draft complete >> >> >> >> After much hard work, the evaluation team has completed the CAPWAP >> evaluation draft. Its is available for review at: >> http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and >> also in the internet drafts directory. >> >> The evaluation team concluded that LWAPP is the most complete proposal >> and should be used as the basis for CAPWAP protocol moving forward. In >> addition, a number of recommendations were made which the evaluation >> team believed should be addressed by the working group. >> >> Over the next 2 weeks the evaluation team will address clarification >> questions on the WG list. The recommendation provided by the >> evaluation team will not change, as this was intended to be an >> independent activity supported by the WG. This is essentially a WGLC >> on the evaluation draft. Please submit any clarification question to >> the list by Friday, September 30th. >> >> The next step will be to come to an agreement on the WG list to decide >> to accept the recommended protocol. Once we have established consensus, >> we can further discuss the additional recommendations presented in the >> draft. >> >> We would like to thank the evaluation team on its thorough work and a >> job well done. >> >> Regards, >> Dorothy and Mani >> >> >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap >> >> >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 13:19:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJ6n-0000xB-2w for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 13:19:25 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26239 for ; Tue, 27 Sep 2005 13:19:09 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF0D02051C; Tue, 27 Sep 2005 13:19:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2ECFA20254; Tue, 27 Sep 2005 13:19:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E412C20506 for ; Tue, 27 Sep 2005 13:18:40 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 41B20204DB for ; Tue, 27 Sep 2005 13:18:37 -0400 (EDT) Message-ID: <03e901c5c387$7f0f2f30$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Wijnen, Bert (Bert)" , "Dan Harkins" Cc: "Capwap (E-mail)" , References: <7D5D48D2CAA3D84C813F5B154F43B15508234A0C@nl0006exch001u.nl.lucent.com> Subject: Re: [Capwap] CAPWAP evaluation draft complete MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 10:18:36 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Let me add a couple of points to Bert's. Some people new to IETF may be unclear how the WG as a whole makes a decision. IETF works by "rough concensus". This doesn't mean that everyone agrees, it doesn't even mean in some cases that a majority of the WG agree. What it means is that the WG chairs have made a concensus call on the mailing list, that enough time is given for WG members to express their opinions and for any discussion, and that, at the conclusion of the discussion period, the WG chairs perform a careful examination of the opinions expressed in the email in order to determine, to their best and honest judgement, what the concensus of the WG is. That decision is then announced on the list as the WG decision, and the WG moves forward with implementing it. Now, in a case as controversial as the current one, there is a high likelihood that someone or some group of WG participants are going to be unhappy with the outcome (this is not a certainty, but it does happen). In that case, the unhappy participants are free to appeal the case to the shepherding AD (in this case, Bert), if they think the WG chairs have misread concensus or somehow not taken something into account (or in cases of gross mismanagement). If Bert decides against them, the unhappy parties are then free to appeal to the IESG, and, ultimately, to the IAB. Appeals are not as unusual as is often thought, but they rarely succeed just because some group of WG participants doesn't like a technical decision. Appeals on technical grounds are usually only successful if the concensus decision somehow neglected to consider some fairly basic technical points which the AD, IESG, or IAB feel is vital to maintaining a consistent and technically sound Internet protocol suite. Nevertheless, the appeals process is there for people who are unhappy with the results of a WG decision. More details can be found in the relevant RFCs/BCPs involved in working group procedure (which, in any case, are the definitive reference and supercede my description above if there is any difference) but I hope that people will keep in mind this procedure as we go forward to avoid any misunderstandings. jak ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: "Dan Harkins" Cc: "Capwap (E-mail)" ; Sent: Monday, September 26, 2005 1:33 PM Subject: RE: [Capwap] CAPWAP evaluation draft complete > Inline, speaking as an individual > >> -----Original Message----- >> From: Dan Harkins [mailto:dharkins@trpz.com] >> Sent: Monday, September 26, 2005 18:15 >> To: Wijnen, Bert (Bert) >> Cc: Capwap (E-mail); david.kessens@nokia.com >> Subject: Re: [Capwap] CAPWAP evaluation draft complete >> >> >> Bert, >> >> The way I understand Dorothy's announcment is that the RECOMMENDATION >> cannot be changed by the working group. > > I think if the ET does a recommendation, then that is their > reccommendation. > If we get clarifications over the next week, and as a result of that the > ET > comes to a different conclusion, then the ET might change their > recomendation, > but it is still their recommendation. > > The WG can decide if they want to accpet or reject the recommendation. > >> Right now it's WGLC on their draft and they're to "address clarification >> questions on the WG list". >> > > My understanding is that if the doc is unclear that the WG gets a chance > to ask for clarifications and that such may lead to changes in the > document. The ET may or may not change their recoemmendation based > on that discussion. In the end, it still is a recommendation from > the ET, and it is then up to the WG to accept or reject such > a recommendation. Maybe the WG decides that they want to pick > up part of the recommendation but not all of it. > > That is a separate WG decision. Or at least that is how I look at it. > >> Yes, we can do a wholesale rejection of the draft itself >> (and then it's >> back to square one) but we cannot change their recommendation. It is >> their recommendation that we must accept as is. > > I think there is a difference. > - who are we (anyone) to change someone elses rfecommendation? > It sounds as if you want to change someones opinion or > conclusion after they have studied. You can try, but I do not > think you can OVERRIDE their opinion (i.e recommendation) > >> This is a non-negotiable >> decision (err, RECOMMENDATION) and we're being asked to take >> it or leave it. >> > > I think you/we have the option to > - accept the recommendation as is > - reject the recommendation as a whole > - accept part of the recommendation and add other pieces > > In other words, the evaluation team has documented their findings > and has documented their recommendation. > > The WG can decide what to do with the recommendation. > >> My statement was not one of supporting or rejecting their >> recommendation >> it was pointing out that it's easier to add messages or >> remove messages >> from any of the protocols than it is to change the tunneling >> and security >> components of them. It would've been easier to start with >> SLAPP and add >> the messages that it lacked, and therefore not "most >> complete", then to >> start with LWAPP and replace 4 parts of its foundation with SLAPP's. >> > > So to me it sounds thatr you do not want to accept the recommendation and > to me it sounds as if you have a different recommendation to the WG. > And it seems you have some explanation as to why you think that your > recommendation is better. The WG can look at that too and opine > on your recommendation. > >> I understand the evaluation and how they put LWAPP ahead of >> SLAPP but >> given that none of the proposals are completely satisfactory I don't >> understand why they chose the route they did. They obviously liked the >> security of SLAPP, its flexibility in tunnelling options, and how it >> does tunnelling. So why not start with the base you like and add the >> toppings instead of starting with the toppings and change the base? >> >> Heck, adding a control type in 4.5.1.8 of SLAPP for "LWAPP >> messaging" >> would make this a cut-and-paste exercise! You get the >> security you want, >> the tunnelling options you want, the way to tunnel you want, and the >> "most complete" messaging you want. >> >> As to your question on whether I support or reject their >> recommendation >> I guess I'd have to......> it!>...reject it on >> the grounds that a starting point along the lines of my >> observation above >> would've been easier to work with. >> > > I hope I answered this above > > Bert >> Dan. >> >> On Mon, 26 Sep 2005 08:13:35 +0200 you wrote >> > [dropped WG chairs, and James, they are on the mailing list. >> > and so am I]. >> > >> > W.r.t. >> > > Now I understand that the 4 member evaluation team made >> a decision >> > >> > The evaluation team made a "decision" if you like for itself, >> > but they reported that decision as a RECOMMENDATION to the WG. >> > >> > > that cannot be changed by the WG and that the WG just has >> to accept it >> > >> > The WG CAN accpt it (instead of HAS TO accept it). >> > After all, it is a RECOMMENDATION. >> > >> > >> > Pls do not put words in the mouth of the evaluation team or the >> > chairs. I do not believe any of them has stated that the WG >> > HAS TO accept anything. >> > >> > So James has stated that he supports the recommendation of the >> > team. You seem to not support that. So what do the other WG members >> > think and opine? >> > >> > Bert >> > > but it seems to me that it would be easier to start with SLAPP as >> > > a foundation and to change a few messages here and there >> to address >> > > whatever shortcomings were perceived instead of taking LWAPP and >> > > replacing its foundation-- its security components, how it does >> > > tunneling, and its tunneling options-- with SLAPP's. >> > > >> > > Dan. >> > > >> > > On Thu, 22 Sep 2005 10:56:09 PDT you wrote >> > > > Dorothy and Mani, >> > > > >> > > > After reading the evaluation document, I support the >> > > recommendation of the >> > > > evaluation team. I hope the WG will be able to resolve the >> > > lingering >> > > > nontechnical issues fairly quickly and move forward with >> > > completing the >> > > > CAPWAP protocol based on the evaluation document's >> recommendations. >> > > > >> > > > I would also suggest that someone with good writing skills >> > > do an editing >> > > > pass through the evaluation document before it is submitted >> > > to the IESG, >> > > > since I noticed numerous typos and minor grammatical errors. >> > > > >> > > > jak >> > > > >> > > > ----- Original Message ----- >> > > > From: >> > > > To: >> > > > Cc: ; ; >> > > ; >> > > > >> > > > Sent: Wednesday, September 21, 2005 6:34 PM >> > > > Subject: [Capwap] CAPWAP evaluation draft complete >> > > > >> > > > >> > > > >> > > > After much hard work, the evaluation team has completed >> the CAPWAP >> > > > evaluation draft. Its is available for review at: >> > > > >> > > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and >> > also in the internet drafts directory. >> > >> > The evaluation team concluded that LWAPP is the most complete proposal >> > and should be used as the basis for CAPWAP protocol moving forward. In >> > addition, a number of recommendations were made which the evaluation >> > team believed should be addressed by the working group. >> > >> > Over the next 2 weeks the evaluation team will address clarification >> > questions on the WG list. The recommendation provided by the >> > evaluation team will not change, as this was intended to be an >> > independent activity supported by the WG. This is essentially a WGLC >> > on the evaluation draft. Please submit any clarification question to >> > the list by Friday, September 30th. >> > >> > The next step will be to come to an agreement on the WG list to decide >> > to accept the recommended protocol. Once we have established >> > consensus, >> > we can further discuss the additional recommendations presented in the >> > draft. >> > >> > We would like to thank the evaluation team on its thorough work and a >> > job well done. >> > >> > Regards, >> > Dorothy and Mani >> > >> > >> > _______________________________________________ >> > Capwap mailing list >> > Capwap@frascone.com >> > http://mail.frascone.com/mailman/listinfo/capwap >> > >> > >> > _______________________________________________ >> > Capwap mailing list >> > Capwap@frascone.com >> > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 14:21:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKK4p-0008HX-Nb for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 14:21:20 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29640 for ; Tue, 27 Sep 2005 14:21:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1905C204D0; Tue, 27 Sep 2005 14:21:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E676220254; Tue, 27 Sep 2005 14:21:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 696F220254 for ; Tue, 27 Sep 2005 14:20:44 -0400 (EDT) Received: from smtpout1.bayarea.net (smtpout1.BAYAREA.NET [209.128.95.10]) by mail.frascone.com (Postfix) with ESMTP id 3BC871FD6C for ; Tue, 27 Sep 2005 14:20:41 -0400 (EDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j8RIKjBT012514; Tue, 27 Sep 2005 11:20:45 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j8RIKcDE031003; Tue, 27 Sep 2005 11:20:38 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j8RIKbeO030999; Tue, 27 Sep 2005 11:20:37 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: James Kempf Cc: "Wijnen, Bert (Bert)" , Dan Harkins , "Capwap (E-mail)" , david.kessens@nokia.com Subject: Re: [Capwap] CAPWAP evaluation draft complete In-Reply-To: <03e901c5c387$7f0f2f30$196115ac@dcml.docomolabsusa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 11:20:37 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) HI, The fundamental part of this is what does "concensus" mean. I believe that many people do not understand what this means. Would you explain. On Tue, 27 Sep 2005, James Kempf wrote: > Let me add a couple of points to Bert's. > > Some people new to IETF may be unclear how the WG as a whole makes a > decision. IETF works by "rough concensus". This doesn't mean that everyone > agrees, it doesn't even mean in some cases that a majority of the WG agree. > What it means is that the WG chairs have made a concensus call on the > mailing list, that enough time is given for WG members to express their > opinions and for any discussion, and that, at the conclusion of the > discussion period, the WG chairs perform a careful examination of the > opinions expressed in the email in order to determine, to their best and > honest judgement, what the concensus of the WG is. That decision is then > announced on the list as the WG decision, and the WG moves forward with > implementing it. > > Now, in a case as controversial as the current one, there is a high > likelihood that someone or some group of WG participants are going to be > unhappy with the outcome (this is not a certainty, but it does happen). In > that case, the unhappy participants are free to appeal the case to the > shepherding AD (in this case, Bert), if they think the WG chairs have > misread concensus or somehow not taken something into account (or in cases > of gross mismanagement). If Bert decides against them, the unhappy parties > are then free to appeal to the IESG, and, ultimately, to the IAB. > > Appeals are not as unusual as is often thought, but they rarely succeed just > because some group of WG participants doesn't like a technical decision. > Appeals on technical grounds are usually only successful if the concensus > decision somehow neglected to consider some fairly basic technical points > which the AD, IESG, or IAB feel is vital to maintaining a consistent and > technically sound Internet protocol suite. Nevertheless, the appeals process > is there for people who are unhappy with the results of a WG decision. > > More details can be found in the relevant RFCs/BCPs involved in working > group procedure (which, in any case, are the definitive reference and > supercede my description above if there is any difference) but I hope that > people will keep in mind this procedure as we go forward to avoid any > misunderstandings. > > jak > > ----- Original Message ----- > From: "Wijnen, Bert (Bert)" > To: "Dan Harkins" > Cc: "Capwap (E-mail)" ; > Sent: Monday, September 26, 2005 1:33 PM > Subject: RE: [Capwap] CAPWAP evaluation draft complete > > > > Inline, speaking as an individual > > > >> -----Original Message----- > >> From: Dan Harkins [mailto:dharkins@trpz.com] > >> Sent: Monday, September 26, 2005 18:15 > >> To: Wijnen, Bert (Bert) > >> Cc: Capwap (E-mail); david.kessens@nokia.com > >> Subject: Re: [Capwap] CAPWAP evaluation draft complete > >> > >> > >> Bert, > >> > >> The way I understand Dorothy's announcment is that the RECOMMENDATION > >> cannot be changed by the working group. > > > > I think if the ET does a recommendation, then that is their > > reccommendation. > > If we get clarifications over the next week, and as a result of that the > > ET > > comes to a different conclusion, then the ET might change their > > recomendation, > > but it is still their recommendation. > > > > The WG can decide if they want to accpet or reject the recommendation. > > > >> Right now it's WGLC on their draft and they're to "address clarification > >> questions on the WG list". > >> > > > > My understanding is that if the doc is unclear that the WG gets a chance > > to ask for clarifications and that such may lead to changes in the > > document. The ET may or may not change their recoemmendation based > > on that discussion. In the end, it still is a recommendation from > > the ET, and it is then up to the WG to accept or reject such > > a recommendation. Maybe the WG decides that they want to pick > > up part of the recommendation but not all of it. > > > > That is a separate WG decision. Or at least that is how I look at it. > > > >> Yes, we can do a wholesale rejection of the draft itself > >> (and then it's > >> back to square one) but we cannot change their recommendation. It is > >> their recommendation that we must accept as is. > > > > I think there is a difference. > > - who are we (anyone) to change someone elses rfecommendation? > > It sounds as if you want to change someones opinion or > > conclusion after they have studied. You can try, but I do not > > think you can OVERRIDE their opinion (i.e recommendation) > > > >> This is a non-negotiable > >> decision (err, RECOMMENDATION) and we're being asked to take > >> it or leave it. > >> > > > > I think you/we have the option to > > - accept the recommendation as is > > - reject the recommendation as a whole > > - accept part of the recommendation and add other pieces > > > > In other words, the evaluation team has documented their findings > > and has documented their recommendation. > > > > The WG can decide what to do with the recommendation. > > > >> My statement was not one of supporting or rejecting their > >> recommendation > >> it was pointing out that it's easier to add messages or > >> remove messages > >> from any of the protocols than it is to change the tunneling > >> and security > >> components of them. It would've been easier to start with > >> SLAPP and add > >> the messages that it lacked, and therefore not "most > >> complete", then to > >> start with LWAPP and replace 4 parts of its foundation with SLAPP's. > >> > > > > So to me it sounds thatr you do not want to accept the recommendation and > > to me it sounds as if you have a different recommendation to the WG. > > And it seems you have some explanation as to why you think that your > > recommendation is better. The WG can look at that too and opine > > on your recommendation. > > > >> I understand the evaluation and how they put LWAPP ahead of > >> SLAPP but > >> given that none of the proposals are completely satisfactory I don't > >> understand why they chose the route they did. They obviously liked the > >> security of SLAPP, its flexibility in tunnelling options, and how it > >> does tunnelling. So why not start with the base you like and add the > >> toppings instead of starting with the toppings and change the base? > >> > >> Heck, adding a control type in 4.5.1.8 of SLAPP for "LWAPP > >> messaging" > >> would make this a cut-and-paste exercise! You get the > >> security you want, > >> the tunnelling options you want, the way to tunnel you want, and the > >> "most complete" messaging you want. > >> > >> As to your question on whether I support or reject their > >> recommendation > >> I guess I'd have to...... >> it!>...reject it on > >> the grounds that a starting point along the lines of my > >> observation above > >> would've been easier to work with. > >> > > > > I hope I answered this above > > > > Bert > >> Dan. > >> > >> On Mon, 26 Sep 2005 08:13:35 +0200 you wrote > >> > [dropped WG chairs, and James, they are on the mailing list. > >> > and so am I]. > >> > > >> > W.r.t. > >> > > Now I understand that the 4 member evaluation team made > >> a decision > >> > > >> > The evaluation team made a "decision" if you like for itself, > >> > but they reported that decision as a RECOMMENDATION to the WG. > >> > > >> > > that cannot be changed by the WG and that the WG just has > >> to accept it > >> > > >> > The WG CAN accpt it (instead of HAS TO accept it). > >> > After all, it is a RECOMMENDATION. > >> > > >> > > >> > Pls do not put words in the mouth of the evaluation team or the > >> > chairs. I do not believe any of them has stated that the WG > >> > HAS TO accept anything. > >> > > >> > So James has stated that he supports the recommendation of the > >> > team. You seem to not support that. So what do the other WG members > >> > think and opine? > >> > > >> > Bert > >> > > but it seems to me that it would be easier to start with SLAPP as > >> > > a foundation and to change a few messages here and there > >> to address > >> > > whatever shortcomings were perceived instead of taking LWAPP and > >> > > replacing its foundation-- its security components, how it does > >> > > tunneling, and its tunneling options-- with SLAPP's. > >> > > > >> > > Dan. > >> > > > >> > > On Thu, 22 Sep 2005 10:56:09 PDT you wrote > >> > > > Dorothy and Mani, > >> > > > > >> > > > After reading the evaluation document, I support the > >> > > recommendation of the > >> > > > evaluation team. I hope the WG will be able to resolve the > >> > > lingering > >> > > > nontechnical issues fairly quickly and move forward with > >> > > completing the > >> > > > CAPWAP protocol based on the evaluation document's > >> recommendations. > >> > > > > >> > > > I would also suggest that someone with good writing skills > >> > > do an editing > >> > > > pass through the evaluation document before it is submitted > >> > > to the IESG, > >> > > > since I noticed numerous typos and minor grammatical errors. > >> > > > > >> > > > jak > >> > > > > >> > > > ----- Original Message ----- > >> > > > From: > >> > > > To: > >> > > > Cc: ; ; > >> > > ; > >> > > > > >> > > > Sent: Wednesday, September 21, 2005 6:34 PM > >> > > > Subject: [Capwap] CAPWAP evaluation draft complete > >> > > > > >> > > > > >> > > > > >> > > > After much hard work, the evaluation team has completed > >> the CAPWAP > >> > > > evaluation draft. Its is available for review at: > >> > > > > >> > > > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and > >> > also in the internet drafts directory. > >> > > >> > The evaluation team concluded that LWAPP is the most complete proposal > >> > and should be used as the basis for CAPWAP protocol moving forward. In > >> > addition, a number of recommendations were made which the evaluation > >> > team believed should be addressed by the working group. > >> > > >> > Over the next 2 weeks the evaluation team will address clarification > >> > questions on the WG list. The recommendation provided by the > >> > evaluation team will not change, as this was intended to be an > >> > independent activity supported by the WG. This is essentially a WGLC > >> > on the evaluation draft. Please submit any clarification question to > >> > the list by Friday, September 30th. > >> > > >> > The next step will be to come to an agreement on the WG list to decide > >> > to accept the recommended protocol. Once we have established > >> > consensus, > >> > we can further discuss the additional recommendations presented in the > >> > draft. > >> > > >> > We would like to thank the evaluation team on its thorough work and a > >> > job well done. > >> > > >> > Regards, > >> > Dorothy and Mani > >> > Regards, /david t. perkins _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 14:29:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKKCb-0002Jo-31 for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 14:29:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29964 for ; Tue, 27 Sep 2005 14:29:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B6CB51FD6C; Tue, 27 Sep 2005 14:29:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 86A5120254; Tue, 27 Sep 2005 14:29:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E800320254 for ; Tue, 27 Sep 2005 14:28:16 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 8BFE31FD6C for ; Tue, 27 Sep 2005 14:28:13 -0400 (EDT) Message-ID: <054001c5c391$37ff7550$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "David T. Perkins" Cc: "Wijnen, Bert (Bert)" , "Dan Harkins" , "Capwap (E-mail)" , References: Subject: Re: [Capwap] CAPWAP evaluation draft complete MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 11:28:12 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit See Section 3.3 of RFC 2418. jak ----- Original Message ----- From: "David T. Perkins" To: "James Kempf" Cc: "Wijnen, Bert (Bert)" ; "Dan Harkins" ; "Capwap (E-mail)" ; Sent: Tuesday, September 27, 2005 11:20 AM Subject: Re: [Capwap] CAPWAP evaluation draft complete > HI, > > The fundamental part of this is what does "concensus" mean. > I believe that many people do not understand what this > means. Would you explain. > > On Tue, 27 Sep 2005, James Kempf wrote: > >> Let me add a couple of points to Bert's. >> >> Some people new to IETF may be unclear how the WG as a whole makes a >> decision. IETF works by "rough concensus". This doesn't mean that >> everyone >> agrees, it doesn't even mean in some cases that a majority of the WG >> agree. >> What it means is that the WG chairs have made a concensus call on the >> mailing list, that enough time is given for WG members to express their >> opinions and for any discussion, and that, at the conclusion of the >> discussion period, the WG chairs perform a careful examination of the >> opinions expressed in the email in order to determine, to their best and >> honest judgement, what the concensus of the WG is. That decision is then >> announced on the list as the WG decision, and the WG moves forward with >> implementing it. >> >> Now, in a case as controversial as the current one, there is a high >> likelihood that someone or some group of WG participants are going to be >> unhappy with the outcome (this is not a certainty, but it does happen). >> In >> that case, the unhappy participants are free to appeal the case to the >> shepherding AD (in this case, Bert), if they think the WG chairs have >> misread concensus or somehow not taken something into account (or in >> cases >> of gross mismanagement). If Bert decides against them, the unhappy >> parties >> are then free to appeal to the IESG, and, ultimately, to the IAB. >> >> Appeals are not as unusual as is often thought, but they rarely succeed >> just >> because some group of WG participants doesn't like a technical decision. >> Appeals on technical grounds are usually only successful if the concensus >> decision somehow neglected to consider some fairly basic technical points >> which the AD, IESG, or IAB feel is vital to maintaining a consistent and >> technically sound Internet protocol suite. Nevertheless, the appeals >> process >> is there for people who are unhappy with the results of a WG decision. >> >> More details can be found in the relevant RFCs/BCPs involved in working >> group procedure (which, in any case, are the definitive reference and >> supercede my description above if there is any difference) but I hope >> that >> people will keep in mind this procedure as we go forward to avoid any >> misunderstandings. >> >> jak >> >> ----- Original Message ----- >> From: "Wijnen, Bert (Bert)" >> To: "Dan Harkins" >> Cc: "Capwap (E-mail)" ; >> Sent: Monday, September 26, 2005 1:33 PM >> Subject: RE: [Capwap] CAPWAP evaluation draft complete >> >> >> > Inline, speaking as an individual >> > >> >> -----Original Message----- >> >> From: Dan Harkins [mailto:dharkins@trpz.com] >> >> Sent: Monday, September 26, 2005 18:15 >> >> To: Wijnen, Bert (Bert) >> >> Cc: Capwap (E-mail); david.kessens@nokia.com >> >> Subject: Re: [Capwap] CAPWAP evaluation draft complete >> >> >> >> >> >> Bert, >> >> >> >> The way I understand Dorothy's announcment is that the >> >> RECOMMENDATION >> >> cannot be changed by the working group. >> > >> > I think if the ET does a recommendation, then that is their >> > reccommendation. >> > If we get clarifications over the next week, and as a result of that >> > the >> > ET >> > comes to a different conclusion, then the ET might change their >> > recomendation, >> > but it is still their recommendation. >> > >> > The WG can decide if they want to accpet or reject the recommendation. >> > >> >> Right now it's WGLC on their draft and they're to "address >> >> clarification >> >> questions on the WG list". >> >> >> > >> > My understanding is that if the doc is unclear that the WG gets a >> > chance >> > to ask for clarifications and that such may lead to changes in the >> > document. The ET may or may not change their recoemmendation based >> > on that discussion. In the end, it still is a recommendation from >> > the ET, and it is then up to the WG to accept or reject such >> > a recommendation. Maybe the WG decides that they want to pick >> > up part of the recommendation but not all of it. >> > >> > That is a separate WG decision. Or at least that is how I look at it. >> > >> >> Yes, we can do a wholesale rejection of the draft itself >> >> (and then it's >> >> back to square one) but we cannot change their recommendation. It is >> >> their recommendation that we must accept as is. >> > >> > I think there is a difference. >> > - who are we (anyone) to change someone elses rfecommendation? >> > It sounds as if you want to change someones opinion or >> > conclusion after they have studied. You can try, but I do not >> > think you can OVERRIDE their opinion (i.e recommendation) >> > >> >> This is a non-negotiable >> >> decision (err, RECOMMENDATION) and we're being asked to take >> >> it or leave it. >> >> >> > >> > I think you/we have the option to >> > - accept the recommendation as is >> > - reject the recommendation as a whole >> > - accept part of the recommendation and add other pieces >> > >> > In other words, the evaluation team has documented their findings >> > and has documented their recommendation. >> > >> > The WG can decide what to do with the recommendation. >> > >> >> My statement was not one of supporting or rejecting their >> >> recommendation >> >> it was pointing out that it's easier to add messages or >> >> remove messages >> >> from any of the protocols than it is to change the tunneling >> >> and security >> >> components of them. It would've been easier to start with >> >> SLAPP and add >> >> the messages that it lacked, and therefore not "most >> >> complete", then to >> >> start with LWAPP and replace 4 parts of its foundation with SLAPP's. >> >> >> > >> > So to me it sounds thatr you do not want to accept the recommendation >> > and >> > to me it sounds as if you have a different recommendation to the WG. >> > And it seems you have some explanation as to why you think that your >> > recommendation is better. The WG can look at that too and opine >> > on your recommendation. >> > >> >> I understand the evaluation and how they put LWAPP ahead of >> >> SLAPP but >> >> given that none of the proposals are completely satisfactory I don't >> >> understand why they chose the route they did. They obviously liked the >> >> security of SLAPP, its flexibility in tunnelling options, and how it >> >> does tunnelling. So why not start with the base you like and add the >> >> toppings instead of starting with the toppings and change the base? >> >> >> >> Heck, adding a control type in 4.5.1.8 of SLAPP for "LWAPP >> >> messaging" >> >> would make this a cut-and-paste exercise! You get the >> >> security you want, >> >> the tunnelling options you want, the way to tunnel you want, and the >> >> "most complete" messaging you want. >> >> >> >> As to your question on whether I support or reject their >> >> recommendation >> >> I guess I'd have to......> >> it!>...reject it on >> >> the grounds that a starting point along the lines of my >> >> observation above >> >> would've been easier to work with. >> >> >> > >> > I hope I answered this above >> > >> > Bert >> >> Dan. >> >> >> >> On Mon, 26 Sep 2005 08:13:35 +0200 you wrote >> >> > [dropped WG chairs, and James, they are on the mailing list. >> >> > and so am I]. >> >> > >> >> > W.r.t. >> >> > > Now I understand that the 4 member evaluation team made >> >> a decision >> >> > >> >> > The evaluation team made a "decision" if you like for itself, >> >> > but they reported that decision as a RECOMMENDATION to the WG. >> >> > >> >> > > that cannot be changed by the WG and that the WG just has >> >> to accept it >> >> > >> >> > The WG CAN accpt it (instead of HAS TO accept it). >> >> > After all, it is a RECOMMENDATION. >> >> > >> >> > >> >> > Pls do not put words in the mouth of the evaluation team or the >> >> > chairs. I do not believe any of them has stated that the WG >> >> > HAS TO accept anything. >> >> > >> >> > So James has stated that he supports the recommendation of the >> >> > team. You seem to not support that. So what do the other WG members >> >> > think and opine? >> >> > >> >> > Bert >> >> > > but it seems to me that it would be easier to start with SLAPP as >> >> > > a foundation and to change a few messages here and there >> >> to address >> >> > > whatever shortcomings were perceived instead of taking LWAPP and >> >> > > replacing its foundation-- its security components, how it does >> >> > > tunneling, and its tunneling options-- with SLAPP's. >> >> > > >> >> > > Dan. >> >> > > >> >> > > On Thu, 22 Sep 2005 10:56:09 PDT you wrote >> >> > > > Dorothy and Mani, >> >> > > > >> >> > > > After reading the evaluation document, I support the >> >> > > recommendation of the >> >> > > > evaluation team. I hope the WG will be able to resolve the >> >> > > lingering >> >> > > > nontechnical issues fairly quickly and move forward with >> >> > > completing the >> >> > > > CAPWAP protocol based on the evaluation document's >> >> recommendations. >> >> > > > >> >> > > > I would also suggest that someone with good writing skills >> >> > > do an editing >> >> > > > pass through the evaluation document before it is submitted >> >> > > to the IESG, >> >> > > > since I noticed numerous typos and minor grammatical errors. >> >> > > > >> >> > > > jak >> >> > > > >> >> > > > ----- Original Message ----- >> >> > > > From: >> >> > > > To: >> >> > > > Cc: ; ; >> >> > > ; >> >> > > > >> >> > > > Sent: Wednesday, September 21, 2005 6:34 PM >> >> > > > Subject: [Capwap] CAPWAP evaluation draft complete >> >> > > > >> >> > > > >> >> > > > >> >> > > > After much hard work, the evaluation team has completed >> >> the CAPWAP >> >> > > > evaluation draft. Its is available for review at: >> >> > > > >> >> > >> > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and >> >> > also in the internet drafts directory. >> >> > >> >> > The evaluation team concluded that LWAPP is the most complete >> >> > proposal >> >> > and should be used as the basis for CAPWAP protocol moving forward. >> >> > In >> >> > addition, a number of recommendations were made which the evaluation >> >> > team believed should be addressed by the working group. >> >> > >> >> > Over the next 2 weeks the evaluation team will address clarification >> >> > questions on the WG list. The recommendation provided by the >> >> > evaluation team will not change, as this was intended to be an >> >> > independent activity supported by the WG. This is essentially a >> >> > WGLC >> >> > on the evaluation draft. Please submit any clarification question >> >> > to >> >> > the list by Friday, September 30th. >> >> > >> >> > The next step will be to come to an agreement on the WG list to >> >> > decide >> >> > to accept the recommended protocol. Once we have established >> >> > consensus, >> >> > we can further discuss the additional recommendations presented in >> >> > the >> >> > draft. >> >> > >> >> > We would like to thank the evaluation team on its thorough work and >> >> > a >> >> > job well done. >> >> > >> >> > Regards, >> >> > Dorothy and Mani >> >> > > > > Regards, > /david t. perkins > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 14:39:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKKMG-0004gv-5b for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 14:39:17 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00520 for ; Tue, 27 Sep 2005 14:39:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3E8A2045A; Tue, 27 Sep 2005 14:39:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D77F620254; Tue, 27 Sep 2005 14:39:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8538920254 for ; Tue, 27 Sep 2005 14:38:53 -0400 (EDT) Received: from smtpout1.bayarea.net (smtpout1.BAYAREA.NET [209.128.95.10]) by mail.frascone.com (Postfix) with ESMTP id 82AF91FD6C for ; Tue, 27 Sep 2005 14:38:50 -0400 (EDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j8RIcoBT017046; Tue, 27 Sep 2005 11:38:50 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j8RIchEr003813; Tue, 27 Sep 2005 11:38:43 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j8RIchCJ003810; Tue, 27 Sep 2005 11:38:43 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: James Kempf Cc: "Capwap (E-mail)" , sob@harvard.edu Subject: Re: [Capwap] CAPWAP evaluation draft complete In-Reply-To: <054001c5c391$37ff7550$196115ac@dcml.docomolabsusa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 11:38:43 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) HI, Regrettably, concensus is not really explained there! Would you like to give it a go for your definition. Regards, /david t. perkins On Tue, 27 Sep 2005, James Kempf wrote: > See Section 3.3 of RFC 2418. > > jak > > ----- Original Message ----- > From: "David T. Perkins" > To: "James Kempf" > Cc: "Wijnen, Bert (Bert)" ; "Dan Harkins" > ; "Capwap (E-mail)" ; > > Sent: Tuesday, September 27, 2005 11:20 AM > Subject: Re: [Capwap] CAPWAP evaluation draft complete > > > > HI, > > > > The fundamental part of this is what does "concensus" mean. > > I believe that many people do not understand what this > > means. Would you explain. > > > > On Tue, 27 Sep 2005, James Kempf wrote: > > > >> Let me add a couple of points to Bert's. > >> > >> Some people new to IETF may be unclear how the WG as a whole makes a > >> decision. IETF works by "rough concensus". This doesn't mean that > >> everyone > >> agrees, it doesn't even mean in some cases that a majority of the WG > >> agree. > >> What it means is that the WG chairs have made a concensus call on the > >> mailing list, that enough time is given for WG members to express their > >> opinions and for any discussion, and that, at the conclusion of the > >> discussion period, the WG chairs perform a careful examination of the > >> opinions expressed in the email in order to determine, to their best and > >> honest judgement, what the concensus of the WG is. That decision is then > >> announced on the list as the WG decision, and the WG moves forward with > >> implementing it. > >> > >> Now, in a case as controversial as the current one, there is a high > >> likelihood that someone or some group of WG participants are going to be > >> unhappy with the outcome (this is not a certainty, but it does happen). > >> In > >> that case, the unhappy participants are free to appeal the case to the > >> shepherding AD (in this case, Bert), if they think the WG chairs have > >> misread concensus or somehow not taken something into account (or in > >> cases > >> of gross mismanagement). If Bert decides against them, the unhappy > >> parties > >> are then free to appeal to the IESG, and, ultimately, to the IAB. > >> > >> Appeals are not as unusual as is often thought, but they rarely succeed > >> just > >> because some group of WG participants doesn't like a technical decision. > >> Appeals on technical grounds are usually only successful if the concensus > >> decision somehow neglected to consider some fairly basic technical points > >> which the AD, IESG, or IAB feel is vital to maintaining a consistent and > >> technically sound Internet protocol suite. Nevertheless, the appeals > >> process > >> is there for people who are unhappy with the results of a WG decision. > >> > >> More details can be found in the relevant RFCs/BCPs involved in working > >> group procedure (which, in any case, are the definitive reference and > >> supercede my description above if there is any difference) but I hope > >> that > >> people will keep in mind this procedure as we go forward to avoid any > >> misunderstandings. > >> > >> jak > >> > >> ----- Original Message ----- > >> From: "Wijnen, Bert (Bert)" > >> To: "Dan Harkins" > >> Cc: "Capwap (E-mail)" ; > >> Sent: Monday, September 26, 2005 1:33 PM > >> Subject: RE: [Capwap] CAPWAP evaluation draft complete > >> > >> > >> > Inline, speaking as an individual > >> > > >> >> -----Original Message----- > >> >> From: Dan Harkins [mailto:dharkins@trpz.com] > >> >> Sent: Monday, September 26, 2005 18:15 > >> >> To: Wijnen, Bert (Bert) > >> >> Cc: Capwap (E-mail); david.kessens@nokia.com > >> >> Subject: Re: [Capwap] CAPWAP evaluation draft complete > >> >> > >> >> > >> >> Bert, > >> >> > >> >> The way I understand Dorothy's announcment is that the > >> >> RECOMMENDATION > >> >> cannot be changed by the working group. > >> > > >> > I think if the ET does a recommendation, then that is their > >> > reccommendation. > >> > If we get clarifications over the next week, and as a result of that > >> > the > >> > ET > >> > comes to a different conclusion, then the ET might change their > >> > recomendation, > >> > but it is still their recommendation. > >> > > >> > The WG can decide if they want to accpet or reject the recommendation. > >> > > >> >> Right now it's WGLC on their draft and they're to "address > >> >> clarification > >> >> questions on the WG list". > >> >> > >> > > >> > My understanding is that if the doc is unclear that the WG gets a > >> > chance > >> > to ask for clarifications and that such may lead to changes in the > >> > document. The ET may or may not change their recoemmendation based > >> > on that discussion. In the end, it still is a recommendation from > >> > the ET, and it is then up to the WG to accept or reject such > >> > a recommendation. Maybe the WG decides that they want to pick > >> > up part of the recommendation but not all of it. > >> > > >> > That is a separate WG decision. Or at least that is how I look at it. > >> > > >> >> Yes, we can do a wholesale rejection of the draft itself > >> >> (and then it's > >> >> back to square one) but we cannot change their recommendation. It is > >> >> their recommendation that we must accept as is. > >> > > >> > I think there is a difference. > >> > - who are we (anyone) to change someone elses rfecommendation? > >> > It sounds as if you want to change someones opinion or > >> > conclusion after they have studied. You can try, but I do not > >> > think you can OVERRIDE their opinion (i.e recommendation) > >> > > >> >> This is a non-negotiable > >> >> decision (err, RECOMMENDATION) and we're being asked to take > >> >> it or leave it. > >> >> > >> > > >> > I think you/we have the option to > >> > - accept the recommendation as is > >> > - reject the recommendation as a whole > >> > - accept part of the recommendation and add other pieces > >> > > >> > In other words, the evaluation team has documented their findings > >> > and has documented their recommendation. > >> > > >> > The WG can decide what to do with the recommendation. > >> > > >> >> My statement was not one of supporting or rejecting their > >> >> recommendation > >> >> it was pointing out that it's easier to add messages or > >> >> remove messages > >> >> from any of the protocols than it is to change the tunneling > >> >> and security > >> >> components of them. It would've been easier to start with > >> >> SLAPP and add > >> >> the messages that it lacked, and therefore not "most > >> >> complete", then to > >> >> start with LWAPP and replace 4 parts of its foundation with SLAPP's. > >> >> > >> > > >> > So to me it sounds thatr you do not want to accept the recommendation > >> > and > >> > to me it sounds as if you have a different recommendation to the WG. > >> > And it seems you have some explanation as to why you think that your > >> > recommendation is better. The WG can look at that too and opine > >> > on your recommendation. > >> > > >> >> I understand the evaluation and how they put LWAPP ahead of > >> >> SLAPP but > >> >> given that none of the proposals are completely satisfactory I don't > >> >> understand why they chose the route they did. They obviously liked the > >> >> security of SLAPP, its flexibility in tunnelling options, and how it > >> >> does tunnelling. So why not start with the base you like and add the > >> >> toppings instead of starting with the toppings and change the base? > >> >> > >> >> Heck, adding a control type in 4.5.1.8 of SLAPP for "LWAPP > >> >> messaging" > >> >> would make this a cut-and-paste exercise! You get the > >> >> security you want, > >> >> the tunnelling options you want, the way to tunnel you want, and the > >> >> "most complete" messaging you want. > >> >> > >> >> As to your question on whether I support or reject their > >> >> recommendation > >> >> I guess I'd have to...... >> >> it!>...reject it on > >> >> the grounds that a starting point along the lines of my > >> >> observation above > >> >> would've been easier to work with. > >> >> > >> > > >> > I hope I answered this above > >> > > >> > Bert > >> >> Dan. > >> >> > >> >> On Mon, 26 Sep 2005 08:13:35 +0200 you wrote > >> >> > [dropped WG chairs, and James, they are on the mailing list. > >> >> > and so am I]. > >> >> > > >> >> > W.r.t. > >> >> > > Now I understand that the 4 member evaluation team made > >> >> a decision > >> >> > > >> >> > The evaluation team made a "decision" if you like for itself, > >> >> > but they reported that decision as a RECOMMENDATION to the WG. > >> >> > > >> >> > > that cannot be changed by the WG and that the WG just has > >> >> to accept it > >> >> > > >> >> > The WG CAN accpt it (instead of HAS TO accept it). > >> >> > After all, it is a RECOMMENDATION. > >> >> > > >> >> > > >> >> > Pls do not put words in the mouth of the evaluation team or the > >> >> > chairs. I do not believe any of them has stated that the WG > >> >> > HAS TO accept anything. > >> >> > > >> >> > So James has stated that he supports the recommendation of the > >> >> > team. You seem to not support that. So what do the other WG members > >> >> > think and opine? > >> >> > > >> >> > Bert > >> >> > > but it seems to me that it would be easier to start with SLAPP as > >> >> > > a foundation and to change a few messages here and there > >> >> to address > >> >> > > whatever shortcomings were perceived instead of taking LWAPP and > >> >> > > replacing its foundation-- its security components, how it does > >> >> > > tunneling, and its tunneling options-- with SLAPP's. > >> >> > > > >> >> > > Dan. > >> >> > > > >> >> > > On Thu, 22 Sep 2005 10:56:09 PDT you wrote > >> >> > > > Dorothy and Mani, > >> >> > > > > >> >> > > > After reading the evaluation document, I support the > >> >> > > recommendation of the > >> >> > > > evaluation team. I hope the WG will be able to resolve the > >> >> > > lingering > >> >> > > > nontechnical issues fairly quickly and move forward with > >> >> > > completing the > >> >> > > > CAPWAP protocol based on the evaluation document's > >> >> recommendations. > >> >> > > > > >> >> > > > I would also suggest that someone with good writing skills > >> >> > > do an editing > >> >> > > > pass through the evaluation document before it is submitted > >> >> > > to the IESG, > >> >> > > > since I noticed numerous typos and minor grammatical errors. > >> >> > > > > >> >> > > > jak > >> >> > > > > >> >> > > > ----- Original Message ----- > >> >> > > > From: > >> >> > > > To: > >> >> > > > Cc: ; ; > >> >> > > ; > >> >> > > > > >> >> > > > Sent: Wednesday, September 21, 2005 6:34 PM > >> >> > > > Subject: [Capwap] CAPWAP evaluation draft complete > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > After much hard work, the evaluation team has completed > >> >> the CAPWAP > >> >> > > > evaluation draft. Its is available for review at: > >> >> > > > > >> >> > > >> > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and > >> >> > also in the internet drafts directory. > >> >> > > >> >> > The evaluation team concluded that LWAPP is the most complete > >> >> > proposal > >> >> > and should be used as the basis for CAPWAP protocol moving forward. > >> >> > In > >> >> > addition, a number of recommendations were made which the evaluation > >> >> > team believed should be addressed by the working group. > >> >> > > >> >> > Over the next 2 weeks the evaluation team will address clarification > >> >> > questions on the WG list. The recommendation provided by the > >> >> > evaluation team will not change, as this was intended to be an > >> >> > independent activity supported by the WG. This is essentially a > >> >> > WGLC > >> >> > on the evaluation draft. Please submit any clarification question > >> >> > to > >> >> > the list by Friday, September 30th. > >> >> > > >> >> > The next step will be to come to an agreement on the WG list to > >> >> > decide > >> >> > to accept the recommended protocol. Once we have established > >> >> > consensus, > >> >> > we can further discuss the additional recommendations presented in > >> >> > the > >> >> > draft. > >> >> > > >> >> > We would like to thank the evaluation team on its thorough work and > >> >> > a > >> >> > job well done. > >> >> > > >> >> > Regards, > >> >> > Dorothy and Mani > >> >> > > > > > > > Regards, > > /david t. perkins > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 17:10:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKMiP-0004B2-C3 for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 17:10:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21277 for ; Tue, 27 Sep 2005 17:10:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DEED420427; Tue, 27 Sep 2005 17:10:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ED8CA202AF; Tue, 27 Sep 2005 17:10:06 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61E2D202AF for ; Tue, 27 Sep 2005 17:09:56 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id DFCA91FE02 for ; Tue, 27 Sep 2005 17:09:53 -0400 (EDT) Message-ID: <058101c5c3a7$cd4d7f10$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "David T. Perkins" Cc: "Capwap (E-mail)" , References: Subject: Re: [Capwap] CAPWAP evaluation draft complete MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 14:09:51 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit No. Section 3.3 describes how consensus is arrived at. jak ----- Original Message ----- From: "David T. Perkins" To: "James Kempf" Cc: "Capwap (E-mail)" ; Sent: Tuesday, September 27, 2005 11:38 AM Subject: Re: [Capwap] CAPWAP evaluation draft complete > HI, > > Regrettably, concensus is not really explained there! > > Would you like to give it a go for your definition. > > Regards, > /david t. perkins > > On Tue, 27 Sep 2005, James Kempf wrote: > >> See Section 3.3 of RFC 2418. >> >> jak >> >> ----- Original Message ----- >> From: "David T. Perkins" >> To: "James Kempf" >> Cc: "Wijnen, Bert (Bert)" ; "Dan Harkins" >> ; "Capwap (E-mail)" ; >> >> Sent: Tuesday, September 27, 2005 11:20 AM >> Subject: Re: [Capwap] CAPWAP evaluation draft complete >> >> >> > HI, >> > >> > The fundamental part of this is what does "concensus" mean. >> > I believe that many people do not understand what this >> > means. Would you explain. >> > >> > On Tue, 27 Sep 2005, James Kempf wrote: >> > >> >> Let me add a couple of points to Bert's. >> >> >> >> Some people new to IETF may be unclear how the WG as a whole makes a >> >> decision. IETF works by "rough concensus". This doesn't mean that >> >> everyone >> >> agrees, it doesn't even mean in some cases that a majority of the WG >> >> agree. >> >> What it means is that the WG chairs have made a concensus call on the >> >> mailing list, that enough time is given for WG members to express >> >> their >> >> opinions and for any discussion, and that, at the conclusion of the >> >> discussion period, the WG chairs perform a careful examination of the >> >> opinions expressed in the email in order to determine, to their best >> >> and >> >> honest judgement, what the concensus of the WG is. That decision is >> >> then >> >> announced on the list as the WG decision, and the WG moves forward >> >> with >> >> implementing it. >> >> >> >> Now, in a case as controversial as the current one, there is a high >> >> likelihood that someone or some group of WG participants are going to >> >> be >> >> unhappy with the outcome (this is not a certainty, but it does >> >> happen). >> >> In >> >> that case, the unhappy participants are free to appeal the case to the >> >> shepherding AD (in this case, Bert), if they think the WG chairs have >> >> misread concensus or somehow not taken something into account (or in >> >> cases >> >> of gross mismanagement). If Bert decides against them, the unhappy >> >> parties >> >> are then free to appeal to the IESG, and, ultimately, to the IAB. >> >> >> >> Appeals are not as unusual as is often thought, but they rarely >> >> succeed >> >> just >> >> because some group of WG participants doesn't like a technical >> >> decision. >> >> Appeals on technical grounds are usually only successful if the >> >> concensus >> >> decision somehow neglected to consider some fairly basic technical >> >> points >> >> which the AD, IESG, or IAB feel is vital to maintaining a consistent >> >> and >> >> technically sound Internet protocol suite. Nevertheless, the appeals >> >> process >> >> is there for people who are unhappy with the results of a WG decision. >> >> >> >> More details can be found in the relevant RFCs/BCPs involved in >> >> working >> >> group procedure (which, in any case, are the definitive reference and >> >> supercede my description above if there is any difference) but I hope >> >> that >> >> people will keep in mind this procedure as we go forward to avoid any >> >> misunderstandings. >> >> >> >> jak >> >> >> >> ----- Original Message ----- >> >> From: "Wijnen, Bert (Bert)" >> >> To: "Dan Harkins" >> >> Cc: "Capwap (E-mail)" ; >> >> Sent: Monday, September 26, 2005 1:33 PM >> >> Subject: RE: [Capwap] CAPWAP evaluation draft complete >> >> >> >> >> >> > Inline, speaking as an individual >> >> > >> >> >> -----Original Message----- >> >> >> From: Dan Harkins [mailto:dharkins@trpz.com] >> >> >> Sent: Monday, September 26, 2005 18:15 >> >> >> To: Wijnen, Bert (Bert) >> >> >> Cc: Capwap (E-mail); david.kessens@nokia.com >> >> >> Subject: Re: [Capwap] CAPWAP evaluation draft complete >> >> >> >> >> >> >> >> >> Bert, >> >> >> >> >> >> The way I understand Dorothy's announcment is that the >> >> >> RECOMMENDATION >> >> >> cannot be changed by the working group. >> >> > >> >> > I think if the ET does a recommendation, then that is their >> >> > reccommendation. >> >> > If we get clarifications over the next week, and as a result of that >> >> > the >> >> > ET >> >> > comes to a different conclusion, then the ET might change their >> >> > recomendation, >> >> > but it is still their recommendation. >> >> > >> >> > The WG can decide if they want to accpet or reject the >> >> > recommendation. >> >> > >> >> >> Right now it's WGLC on their draft and they're to "address >> >> >> clarification >> >> >> questions on the WG list". >> >> >> >> >> > >> >> > My understanding is that if the doc is unclear that the WG gets a >> >> > chance >> >> > to ask for clarifications and that such may lead to changes in the >> >> > document. The ET may or may not change their recoemmendation based >> >> > on that discussion. In the end, it still is a recommendation from >> >> > the ET, and it is then up to the WG to accept or reject such >> >> > a recommendation. Maybe the WG decides that they want to pick >> >> > up part of the recommendation but not all of it. >> >> > >> >> > That is a separate WG decision. Or at least that is how I look at >> >> > it. >> >> > >> >> >> Yes, we can do a wholesale rejection of the draft itself >> >> >> (and then it's >> >> >> back to square one) but we cannot change their recommendation. It >> >> >> is >> >> >> their recommendation that we must accept as is. >> >> > >> >> > I think there is a difference. >> >> > - who are we (anyone) to change someone elses rfecommendation? >> >> > It sounds as if you want to change someones opinion or >> >> > conclusion after they have studied. You can try, but I do not >> >> > think you can OVERRIDE their opinion (i.e recommendation) >> >> > >> >> >> This is a non-negotiable >> >> >> decision (err, RECOMMENDATION) and we're being asked to take >> >> >> it or leave it. >> >> >> >> >> > >> >> > I think you/we have the option to >> >> > - accept the recommendation as is >> >> > - reject the recommendation as a whole >> >> > - accept part of the recommendation and add other pieces >> >> > >> >> > In other words, the evaluation team has documented their findings >> >> > and has documented their recommendation. >> >> > >> >> > The WG can decide what to do with the recommendation. >> >> > >> >> >> My statement was not one of supporting or rejecting their >> >> >> recommendation >> >> >> it was pointing out that it's easier to add messages or >> >> >> remove messages >> >> >> from any of the protocols than it is to change the tunneling >> >> >> and security >> >> >> components of them. It would've been easier to start with >> >> >> SLAPP and add >> >> >> the messages that it lacked, and therefore not "most >> >> >> complete", then to >> >> >> start with LWAPP and replace 4 parts of its foundation with >> >> >> SLAPP's. >> >> >> >> >> > >> >> > So to me it sounds thatr you do not want to accept the >> >> > recommendation >> >> > and >> >> > to me it sounds as if you have a different recommendation to the WG. >> >> > And it seems you have some explanation as to why you think that your >> >> > recommendation is better. The WG can look at that too and opine >> >> > on your recommendation. >> >> > >> >> >> I understand the evaluation and how they put LWAPP ahead of >> >> >> SLAPP but >> >> >> given that none of the proposals are completely satisfactory I >> >> >> don't >> >> >> understand why they chose the route they did. They obviously liked >> >> >> the >> >> >> security of SLAPP, its flexibility in tunnelling options, and how >> >> >> it >> >> >> does tunnelling. So why not start with the base you like and add >> >> >> the >> >> >> toppings instead of starting with the toppings and change the base? >> >> >> >> >> >> Heck, adding a control type in 4.5.1.8 of SLAPP for "LWAPP >> >> >> messaging" >> >> >> would make this a cut-and-paste exercise! You get the >> >> >> security you want, >> >> >> the tunnelling options you want, the way to tunnel you want, and >> >> >> the >> >> >> "most complete" messaging you want. >> >> >> >> >> >> As to your question on whether I support or reject their >> >> >> recommendation >> >> >> I guess I'd have to......> >> >> it!>...reject it on >> >> >> the grounds that a starting point along the lines of my >> >> >> observation above >> >> >> would've been easier to work with. >> >> >> >> >> > >> >> > I hope I answered this above >> >> > >> >> > Bert >> >> >> Dan. >> >> >> >> >> >> On Mon, 26 Sep 2005 08:13:35 +0200 you wrote >> >> >> > [dropped WG chairs, and James, they are on the mailing list. >> >> >> > and so am I]. >> >> >> > >> >> >> > W.r.t. >> >> >> > > Now I understand that the 4 member evaluation team made >> >> >> a decision >> >> >> > >> >> >> > The evaluation team made a "decision" if you like for itself, >> >> >> > but they reported that decision as a RECOMMENDATION to the WG. >> >> >> > >> >> >> > > that cannot be changed by the WG and that the WG just has >> >> >> to accept it >> >> >> > >> >> >> > The WG CAN accpt it (instead of HAS TO accept it). >> >> >> > After all, it is a RECOMMENDATION. >> >> >> > >> >> >> > >> >> >> > Pls do not put words in the mouth of the evaluation team or the >> >> >> > chairs. I do not believe any of them has stated that the WG >> >> >> > HAS TO accept anything. >> >> >> > >> >> >> > So James has stated that he supports the recommendation of the >> >> >> > team. You seem to not support that. So what do the other WG >> >> >> > members >> >> >> > think and opine? >> >> >> > >> >> >> > Bert >> >> >> > > but it seems to me that it would be easier to start with SLAPP >> >> >> > > as >> >> >> > > a foundation and to change a few messages here and there >> >> >> to address >> >> >> > > whatever shortcomings were perceived instead of taking LWAPP >> >> >> > > and >> >> >> > > replacing its foundation-- its security components, how it does >> >> >> > > tunneling, and its tunneling options-- with SLAPP's. >> >> >> > > >> >> >> > > Dan. >> >> >> > > >> >> >> > > On Thu, 22 Sep 2005 10:56:09 PDT you wrote >> >> >> > > > Dorothy and Mani, >> >> >> > > > >> >> >> > > > After reading the evaluation document, I support the >> >> >> > > recommendation of the >> >> >> > > > evaluation team. I hope the WG will be able to resolve the >> >> >> > > lingering >> >> >> > > > nontechnical issues fairly quickly and move forward with >> >> >> > > completing the >> >> >> > > > CAPWAP protocol based on the evaluation document's >> >> >> recommendations. >> >> >> > > > >> >> >> > > > I would also suggest that someone with good writing skills >> >> >> > > do an editing >> >> >> > > > pass through the evaluation document before it is submitted >> >> >> > > to the IESG, >> >> >> > > > since I noticed numerous typos and minor grammatical errors. >> >> >> > > > >> >> >> > > > jak >> >> >> > > > >> >> >> > > > ----- Original Message ----- >> >> >> > > > From: >> >> >> > > > To: >> >> >> > > > Cc: ; ; >> >> >> > > ; >> >> >> > > > >> >> >> > > > Sent: Wednesday, September 21, 2005 6:34 PM >> >> >> > > > Subject: [Capwap] CAPWAP evaluation draft complete >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > > > After much hard work, the evaluation team has completed >> >> >> the CAPWAP >> >> >> > > > evaluation draft. Its is available for review at: >> >> >> > > > >> >> >> > >> >> > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt >> >> > and >> >> >> > also in the internet drafts directory. >> >> >> > >> >> >> > The evaluation team concluded that LWAPP is the most complete >> >> >> > proposal >> >> >> > and should be used as the basis for CAPWAP protocol moving >> >> >> > forward. >> >> >> > In >> >> >> > addition, a number of recommendations were made which the >> >> >> > evaluation >> >> >> > team believed should be addressed by the working group. >> >> >> > >> >> >> > Over the next 2 weeks the evaluation team will address >> >> >> > clarification >> >> >> > questions on the WG list. The recommendation provided by the >> >> >> > evaluation team will not change, as this was intended to be an >> >> >> > independent activity supported by the WG. This is essentially a >> >> >> > WGLC >> >> >> > on the evaluation draft. Please submit any clarification >> >> >> > question >> >> >> > to >> >> >> > the list by Friday, September 30th. >> >> >> > >> >> >> > The next step will be to come to an agreement on the WG list to >> >> >> > decide >> >> >> > to accept the recommended protocol. Once we have established >> >> >> > consensus, >> >> >> > we can further discuss the additional recommendations presented >> >> >> > in >> >> >> > the >> >> >> > draft. >> >> >> > >> >> >> > We would like to thank the evaluation team on its thorough work >> >> >> > and >> >> >> > a >> >> >> > job well done. >> >> >> > >> >> >> > Regards, >> >> >> > Dorothy and Mani >> >> >> > >> > >> > >> > Regards, >> > /david t. perkins >> > >> >> > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 19:42:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKP5U-0004mB-5s for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 19:42:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28735 for ; Tue, 27 Sep 2005 19:42:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58C5C2043D; Tue, 27 Sep 2005 19:42:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 77D39202AF; Tue, 27 Sep 2005 19:42:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9774E20377 for ; Tue, 27 Sep 2005 19:41:33 -0400 (EDT) Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 9654F20350 for ; Tue, 27 Sep 2005 19:41:31 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 16:45:53 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 16:41:06 -0700 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] CAPWAP Objectives - Logical Groups Message-ID: Thread-Topic: [Capwap] CAPWAP Objectives - Logical Groups Thread-Index: AcXDM2S3v0pKnvTaTVKsliazai7tqQANPh2gAA/Z/iA= From: "Darren Loher" To: "Pat Calhoun (pacalhou)" , "Saravanan Govindan" , X-OriginalArrivalTime: 27 Sep 2005 23:41:06.0949 (UTC) FILETIME=[EE512350:01C5C3BC] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 16:41:09 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Perhaps this wording would work: "For all operating modes, including those in which the WTP performs local bridging and those in which the AC performs centralized bridging, the protocol MUST provide provisions for configuring logical groups at the WTP." This avoids using "tunneled mode" and "non-tunneled mode"=20 which are not currently defined in the objectives. -Darren > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Pat Calhoun (pacalhou) > Sent: Tuesday, September 27, 2005 7:36 AM > To: Saravanan Govindan; capwap@frascone.com > Subject: RE: [Capwap] CAPWAP Objectives - Logical Groups >=20 > You say: >=20 > > For all operating modes, including those in which the WTP performs > local bridging and > > those in which the AC performs centralized bridging, the protocol MUST > provide provisions > > for configuring logical groups across > > the AC-WTP interface. >=20 > But what does the AC-WTP interface mean when data is locally bridged? >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 >=20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > > Sent: Tuesday, September 27, 2005 12:17 AM > > To: capwap@frascone.com > > Subject: [Capwap] CAPWAP Objectives - Logical Groups > > > > All, > > > > Regarding the Objectives document, it was last suggested that > > the Protocol Requirement for the Logical Groups objective > > (Section 5.1.1) be updated to reflect needs for local-MAC > > architectures. > > > > The current requirement is; > > > > "The CAPWAP protocol MUST be capable of controlling and > > managing physical WTPs in terms of logical groups including > > BSSID-based groups." > > > > > > > > Then it was suggested by Pat to extend with; > > > > "The CAPWAP protocol MUST be capable of controlling and > > managing physical WTPs in terms of logical groups including > > BSSID-based groups. > > > > For non-tunneled mode, the protocols MUST also provide the > > provisions to configure the associated VLAN (or subnet) which > > is to be used by the WTP in bridging traffic for the logical group." > > > > > > > > Since the Objectives draft does not define "non-tunneled > > mode", I'm thinking of rewording for a more clear > > requirement. Consider the following; > > > > "The CAPWAP protocol MUST be capable of controlling and > > managing physical WTPs in terms of logical groups including > > BSSID-based groups. > > > > For all operating modes, including those in which the WTP > > performs local bridging and those in which the AC performs > > centralized bridging, the protocol MUST provide provisions > > for configuring logical groups across > > the AC-WTP interface." > > > > I look forward to any further suggestions on this. > > > > Saravanan _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 21:12:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKQUX-0004i4-MO for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 21:12:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04669 for ; Tue, 27 Sep 2005 21:12:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 047672043D; Tue, 27 Sep 2005 21:12:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E82F2034F; Tue, 27 Sep 2005 21:12:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 482662034F for ; Tue, 27 Sep 2005 21:11:07 -0400 (EDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by mail.frascone.com (Postfix) with ESMTP id BD974202AF for ; Tue, 27 Sep 2005 21:11:04 -0400 (EDT) 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 j8S1Atf6017027; Wed, 28 Sep 2005 10:10:55 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j8S1Avq14680; Wed, 28 Sep 2005 10:10:57 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id j8S1AuA25936; Wed, 28 Sep 2005 10:10:56 +0900 (JST) 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] CAPWAP Objectives - Logical Groups Message-ID: <5F09D220B62F79418461A978CA0921BD67303E@pslexc01.psl.local> Thread-topic: [Capwap] CAPWAP Objectives - Logical Groups Thread-Index: AcXDM2S3v0pKnvTaTVKsliazai7tqQANPh2gAA/Z/iAACDV7UA== From: "Saravanan Govindan" To: "Darren Loher" , "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 09:08:32 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Darren, I think your suggestion rightly reflects the objective's intent.=20 If this is fine with the rest of the WG, we can move forward on the Objectives. Saravanan =20 > -----Original Message----- > From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 > Sent: Wednesday, September 28, 2005 7:41 AM > To: Pat Calhoun (pacalhou); Saravanan Govindan; capwap@frascone.com > Subject: RE: [Capwap] CAPWAP Objectives - Logical Groups >=20 > Perhaps this wording would work: >=20 > "For all operating modes, including those in which the WTP=20 > performs local bridging and those in which the AC performs=20 > centralized bridging, the protocol MUST provide provisions=20 > for configuring logical groups at the WTP." >=20 > This avoids using "tunneled mode" and "non-tunneled mode"=20 > which are not currently defined in the objectives. >=20 > -Darren >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > > Behalf Of Pat Calhoun (pacalhou) > > Sent: Tuesday, September 27, 2005 7:36 AM > > To: Saravanan Govindan; capwap@frascone.com > > Subject: RE: [Capwap] CAPWAP Objectives - Logical Groups > >=20 > > You say: > >=20 > > > For all operating modes, including those in which the WTP performs > > local bridging and > > > those in which the AC performs centralized bridging, the protocol > MUST > > provide provisions > > > for configuring logical groups across the AC-WTP interface. > >=20 > > But what does the AC-WTP interface mean when data is=20 > locally bridged? > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > > > Sent: Tuesday, September 27, 2005 12:17 AM > > > To: capwap@frascone.com > > > Subject: [Capwap] CAPWAP Objectives - Logical Groups > > > > > > All, > > > > > > Regarding the Objectives document, it was last suggested that the=20 > > > Protocol Requirement for the Logical Groups objective (Section=20 > > > 5.1.1) be updated to reflect needs for local-MAC architectures. > > > > > > The current requirement is; > > > > > > "The CAPWAP protocol MUST be capable of controlling and managing=20 > > > physical WTPs in terms of logical groups including BSSID-based=20 > > > groups." > > > > > > > > > > > > Then it was suggested by Pat to extend with; > > > > > > "The CAPWAP protocol MUST be capable of controlling and managing=20 > > > physical WTPs in terms of logical groups including BSSID-based=20 > > > groups. > > > > > > For non-tunneled mode, the protocols MUST also provide the=20 > > > provisions to configure the associated VLAN (or subnet)=20 > which is to=20 > > > be used by the WTP in bridging traffic for the logical group." > > > > > > > > > > > > Since the Objectives draft does not define "non-tunneled=20 > mode", I'm=20 > > > thinking of rewording for a more clear requirement. Consider the=20 > > > following; > > > > > > "The CAPWAP protocol MUST be capable of controlling and managing=20 > > > physical WTPs in terms of logical groups including BSSID-based=20 > > > groups. > > > > > > For all operating modes, including those in which the WTP=20 > performs=20 > > > local bridging and those in which the AC performs centralized=20 > > > bridging, the protocol MUST provide provisions for configuring=20 > > > logical groups across the AC-WTP interface." > > > > > > I look forward to any further suggestions on this. > > > > > > Saravanan >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 21:47:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKR2P-0007Qq-H1 for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 21:47:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06448 for ; Tue, 27 Sep 2005 21:47:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78CDA20427; Tue, 27 Sep 2005 21:47:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7812C202AF; Tue, 27 Sep 2005 21:47:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 917F7202AF for ; Tue, 27 Sep 2005 21:46:39 -0400 (EDT) Received: from staff-mail.rp.edu.sg (smtp.rp.edu.sg [202.21.158.80]) by mail.frascone.com (Postfix) with ESMTP id 9970B20230 for ; Tue, 27 Sep 2005 21:46:35 -0400 (EDT) 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] CAPWAP evaluation draft complete Message-ID: <9C374CF75527504394E573E1937136C401763FF3@staff-mail.rp.edu.sg> Thread-Topic: [Capwap] CAPWAP evaluation draft complete thread-index: AcXC30ArKgYOgSkCQq6cJhzue2e0VgAGvE6AAA5TQbAAJndLUA== From: "Richard Gwee" To: "Saravanan Govindan" , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 09:46:30 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, I also agree with this suggestion. I believe too that having clear protocol attributes will help in developing the CAPWAP protocol. I will be willing to work with the evaluation team in this area. Regards Richard Gwee -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan Sent: Tuesday, September 27, 2005 6:03 PM To: troy@twisted.net; capwap@frascone.com Subject: RE: [Capwap] CAPWAP evaluation draft complete Troy, I like your suggestion of highlighting protocol attributes. I think doing so would help in developing a solid CAPWAP protocol.=20 The CAPWAP Comparative Analysis document seems to be in line with this. It highlights specific mechanisms in the candidate protocols that best address the requirements.=20 The WG can consider incorporating some of the specifics of the Comparative Analysis in the Evaluation draft.=20 Saravanan > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Troy Dixler > Sent: Tuesday, September 27, 2005 8:30 AM > To: capwap@frascone.com > Subject: RE: [Capwap] CAPWAP evaluation draft complete >=20 > I guess I'm not following the logic behind the=20 > recommendation. It seems to me that rather than the group=20 > focusing in on what draft, they should be focusing in on what=20 > attributes they want in the CAPWAP protocol. There are=20 > clearly pieces of both base protocols that bring value to the=20 > working group. > In the end the best pieces will become the basis we work from=20 > to become a standard. >=20 > To pick a "side" when clearly there were attributes that were=20 > not within LWAPP just stirs up politics. >=20 > Why not revise the draft to state the clear attributes and=20 > recommendations that the protocol should contain and not=20 > start with either base draft but start it fresh and call it=20 > by its rightful name CAPWAP. >=20 > -Troy >=20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > > Behalf Of Wijnen, Bert (Bert) > > Sent: Monday, September 26, 2005 4:01 PM > > To: T. Charles Clancy; capwap@frascone.com > > Subject: RE: [Capwap] CAPWAP evaluation draft complete > >=20 > > Inline > >=20 > > > -----Original Message----- > > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com]On > > > Behalf Of T. Charles Clancy > > > Sent: Monday, September 26, 2005 16:14 > > > To: capwap@frascone.com > > > Subject: RE: [Capwap] CAPWAP evaluation draft complete > > > > > > > > > On Mon, 26 Sep 2005, Wijnen, Bert (Bert) wrote: > > > > > > > The evaluation team made a "decision" if you like for > > > itself, but they > > > > reported that decision as a RECOMMENDATION to the WG. > > > > > > Well if we don't take it as more than a RECOMMENDATION, I wonder=20 > > > what the point of an evaluation team was. > > > > >=20 > > I believe the value was en is that we had a dedicated team=20 > of people=20 > > who have meticoulously studied the objectives and the=20 > submission and=20 > > who have after that documented their findings precisely and at then=20 > > end even gave a recommendation. > >=20 > > That is a very useful piece of input for the WG based on which they=20 > > can try to come to a decision as what to do. This in=20 > addition to any=20 > > other input (like your own evaluation etc). > >=20 > > Bert > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 = . Website: www.rp.sg . Fax: +65 6415-1310 . From April 2006, we will be located in our new home at 9 Woodlands = Avenue 9,Singapore 738964=20 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 Quality Class = (SQC) certification, People Developer Standards and QEHS standards (ISO = 9001, 14001 and OHSAS 18001 certifications). --------------------------------------------------------------------- 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. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Sep 27 22:41:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKRsf-0004qd-4S for capwap-archive@megatron.ietf.org; Tue, 27 Sep 2005 22:41:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08684 for ; Tue, 27 Sep 2005 22:41:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8917220427; Tue, 27 Sep 2005 22:41:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 84FD0202AF; Tue, 27 Sep 2005 22:41:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F062A202AF for ; Tue, 27 Sep 2005 22:40:38 -0400 (EDT) Received: from oz.twisted.net (oz.twisted.net [69.211.34.241]) by mail.frascone.com (Postfix) with ESMTP id EC48320230 for ; Tue, 27 Sep 2005 22:40:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by oz.twisted.net (Postfix) with ESMTP id 8C8D5599C9E; Tue, 27 Sep 2005 21:52:37 -0500 (CDT) Received: from oz.twisted.net ([127.0.0.1]) by localhost (oz.twisted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69299-02; Tue, 27 Sep 2005 21:52:37 -0500 (CDT) Received: from noodle (sindrome.twisted.net [172.16.0.5]) by oz.twisted.net (Postfix) with ESMTP id 2FBBC599B68; Tue, 27 Sep 2005 21:52:35 -0500 (CDT) Reply-To: From: "Troy Dixler" To: "'Darren Loher'" , Subject: RE: [Capwap] CAPWAP evaluation draft complete MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXC30ArKgYOgSkCQq6cJhzue2e0VgAGvE6AAB+1LSAAFvzfwA== In-Reply-To: Message-Id: <20050928025235.2FBBC599B68@oz.twisted.net> X-Virus-Scanned: by amavisd-new at twisted.net X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Sep 2005 21:38:59 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > We did consider an approach of a new proposal with the best features of > all the good and interesting capabilities presented. However, as a team > we agreed this would be akin to "starting over" and would likely extend > the standards process by another year, if not longer. I am not in favor > of this, but it is up to working group consensus to decide if a delay > like that is desirable. I understand your theory that starting with one of the drafts would have you believe it would speed up the process, but I do not agree or see how you can arrive at a conclusion that it would take "another year". With the impending IPR claims as well as the fact that both protocols exhibit attributes that would benefit the working group I think we can turn it around rather quickly. The two drafts are simply not that complex. I believe there have been a few voices that have responded to this thread stating that they would like to revisit the draft and define the attributes rather than one or the other for a base draft. I would equally be willing to work on the revised recommendation draft to define the core set of attributes that make up the CAPWAP standard. I believe others on the list would equally be willing to assist. -Troy _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:33:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjY8-0001jW-Ok for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:33:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13713 for ; Wed, 28 Sep 2005 17:33:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A5D6A204F4; Wed, 28 Sep 2005 17:33:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 46E752043D; Wed, 28 Sep 2005 17:33:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 00167204AF for ; Wed, 28 Sep 2005 17:32:20 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 922A01FE16 for ; Wed, 28 Sep 2005 17:32:17 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 28 Sep 2005 14:32:17 -0700 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 j8SLW554006302 for ; Wed, 28 Sep 2005 14:32:15 -0700 (PDT) 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, 28 Sep 2005 14:32:14 -0700 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 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8B780@xmb-sjc-235.amer.cisco.com> Thread-Topic: Overview of requested changes Thread-Index: AcXEYU9gwYNPBRRBTbSVDr7W9v9+Mw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Sep 2005 21:32:15.0079 (UTC) FILETIME=[182D2770:01C5C474] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Overview of requested changes Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:32:14 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable All, =20 I wanted to provide the working group with an overview of the changes being requested by the evaluation team. The purpose of this is twofold. First, I want to make sure that my interpretation of the requested change is accurate, and second, I want to make sure that the WG is comfortable with the requested change. =20 I've decided that in order to minimize the size of the e-mail messages, and to allow folks to comment on the specific change requests they care about, I will create a separate e-mail message for every change request. For every such e-mail sent, I will include the text "Change Request ", where sec-num will be replaced with the section number in the draft-ietf-capwap-eval-00.txt draft, and sec-title will be the section's title. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:33:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjYQ-0001kH-Bw for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:33:30 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13720 for ; Wed, 28 Sep 2005 17:33:27 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 31F0D20531; Wed, 28 Sep 2005 17:33:28 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C2E8520526; Wed, 28 Sep 2005 17:33:23 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65EB0204F4 for ; Wed, 28 Sep 2005 17:32:21 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 2415F2043D for ; Wed, 28 Sep 2005 17:32:18 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 28 Sep 2005 14:32:17 -0700 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 j8SLViKe025384; Wed, 28 Sep 2005 14:32:13 -0700 (PDT) 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, 28 Sep 2005 14:32:13 -0700 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] CAPWAP Objectives - Logical Groups Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8B77E@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] CAPWAP Objectives - Logical Groups Thread-Index: AcXDM2S3v0pKnvTaTVKsliazai7tqQANPh2gAA/Z/iAAKBWNcA== From: "Pat Calhoun (pacalhou)" To: "Darren Loher" , "Saravanan Govindan" , X-OriginalArrivalTime: 28 Sep 2005 21:32:13.0860 (UTC) FILETIME=[17732640:01C5C474] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:32:13 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Works for me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher > Sent: Tuesday, September 27, 2005 4:41 PM > To: Pat Calhoun (pacalhou); Saravanan Govindan; capwap@frascone.com > Subject: RE: [Capwap] CAPWAP Objectives - Logical Groups >=20 > Perhaps this wording would work: >=20 > "For all operating modes, including those in which the WTP=20 > performs local bridging and those in which the AC performs=20 > centralized bridging, the protocol MUST provide provisions=20 > for configuring logical groups at the WTP." >=20 > This avoids using "tunneled mode" and "non-tunneled mode"=20 > which are not currently defined in the objectives. >=20 > -Darren >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > > Behalf Of Pat Calhoun (pacalhou) > > Sent: Tuesday, September 27, 2005 7:36 AM > > To: Saravanan Govindan; capwap@frascone.com > > Subject: RE: [Capwap] CAPWAP Objectives - Logical Groups > >=20 > > You say: > >=20 > > > For all operating modes, including those in which the WTP performs > > local bridging and > > > those in which the AC performs centralized bridging, the protocol > MUST > > provide provisions > > > for configuring logical groups across the AC-WTP interface. > >=20 > > But what does the AC-WTP interface mean when data is=20 > locally bridged? > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan > > > Sent: Tuesday, September 27, 2005 12:17 AM > > > To: capwap@frascone.com > > > Subject: [Capwap] CAPWAP Objectives - Logical Groups > > > > > > All, > > > > > > Regarding the Objectives document, it was last suggested that the=20 > > > Protocol Requirement for the Logical Groups objective (Section=20 > > > 5.1.1) be updated to reflect needs for local-MAC architectures. > > > > > > The current requirement is; > > > > > > "The CAPWAP protocol MUST be capable of controlling and managing=20 > > > physical WTPs in terms of logical groups including BSSID-based=20 > > > groups." > > > > > > > > > > > > Then it was suggested by Pat to extend with; > > > > > > "The CAPWAP protocol MUST be capable of controlling and managing=20 > > > physical WTPs in terms of logical groups including BSSID-based=20 > > > groups. > > > > > > For non-tunneled mode, the protocols MUST also provide the=20 > > > provisions to configure the associated VLAN (or subnet)=20 > which is to=20 > > > be used by the WTP in bridging traffic for the logical group." > > > > > > > > > > > > Since the Objectives draft does not define "non-tunneled=20 > mode", I'm=20 > > > thinking of rewording for a more clear requirement. Consider the=20 > > > following; > > > > > > "The CAPWAP protocol MUST be capable of controlling and managing=20 > > > physical WTPs in terms of logical groups including BSSID-based=20 > > > groups. > > > > > > For all operating modes, including those in which the WTP=20 > performs=20 > > > local bridging and those in which the AC performs centralized=20 > > > bridging, the protocol MUST provide provisions for configuring=20 > > > logical groups across the AC-WTP interface." > > > > > > I look forward to any further suggestions on this. > > > > > > Saravanan > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:33:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjYr-0001xH-Jn for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:33:57 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13742 for ; Wed, 28 Sep 2005 17:33:54 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCB4C20543; Wed, 28 Sep 2005 17:33:54 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8918D2053B; Wed, 28 Sep 2005 17:33:40 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1DA70204AF for ; Wed, 28 Sep 2005 17:32:23 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 13262204BF for ; Wed, 28 Sep 2005 17:32:20 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2005 14:32:20 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208"; a="346480398:sNHT32460092" 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 j8SLW556006302 for ; Wed, 28 Sep 2005 14:32:17 -0700 (PDT) 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, 28 Sep 2005 14:32:16 -0700 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 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8B782@xmb-sjc-235.amer.cisco.com> Thread-Topic: Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXEZKuP1h7jKRGpSuWnnfXZU19Abg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Sep 2005 21:32:16.0220 (UTC) FILETIME=[18DB41C0:01C5C474] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Change Request 9.1.2 (Control Channel Security) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:32:16 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The evaluation team has made a request to modify LWAPP's built-in security mechanism with DTLS instead. This specific change is tricky as we first need to identify whether the DTLS session should be created prior to, or post, the discovery phase. Here are my high level thoughts on the issue: 1. Pre-Discovery DTLS. One of the LWAPP features is load balancing of WTPs among ACs. This load balancing can occur within, or across multiple, ACs. How this works is that a WTP would perform the discovery phase by initiating a Discovery Request packet to one or more ACs. The receiving ACs respond with a Discovery Response, which also includes the total number of WTPs supported (see section 5.2.2), as well as its current WTP load (see section 5.2.3). The WTP collects all of the Discovery Responses, and then decides which AC it wishes to connect to based on its policy. The policy can be either least loaded AC, or through a list of preferred ACs (see section 7.2.3). Further, the WTP can opt to not establish a session with the AC if it determines that it does not have the basic capabilities required by the AC. Performing DTLS prior to the Discovery Request would mean that the WTP would mean one of two things: a. The WTP establishes a DTLS session with every AC it knows about. The side effect here is the LWAPP connect time on the WTP, not to mention the CPU load imposed on the AC. b. The LWAPP protocol eliminates this feature altogether. This means that a WTP would only connect to the AC of its choice, regardless of the AC's current load of configuration. 2. Post-Discovery DTLS. In this mode, the above limitations are removed, and the Discovery phase is done in the clear. While it is true that this raises some security concerns, the information in the Discovery Response is relatively benign, and therefore any malicious tweaking (or altering) of the response packet has created limited damage (although the WG needs to evaluate this, but it was not found to be problematic during the security review). This change would also require that the the Discovery packets be exchanged on a separate UDP port, which is not a big change to the protocol. while I understand the evaluation team's recommendation to adopt DTLS, I would also like to get a larger WG rough consensus on whether we feel that this change should be made. While I will make the change based on rough consensus, I want to make sure that we think and agree on this decision through as a group. I understand the concerns raised about increasing the time of the protocol development phase in having our own security approach, there are strategies that can be done to help us. For instance, initiate another security review with another reviewer identified by Russ Housely asap (he did recommend Charles Clancy, btw).=20 I think that another important point here is that during a recent meeting with NIST, we discussed the transport of 802.11i PMKs within the RADIUS protocol. During this discussion, we proposed two methods. The first would explicitely encrypt the PMK using AES-KeyWrap within a RADIUS attribute. The second approach was simply to encrypt the whole RADIUS transaction with IPSec. It was NIST's opinion at that time that they felt comfortable with option one, while option two would require them to evaluate whether IPSec would be appropriate for the transport of PMKs. Given that CAPWAP has a requirement to allow the WTP to perform encryption, this means that PTKs (and GTKs) would have to be transported over a DTLS session, and therefore I wonder whether we would have similar issues as those mentioned above. If this were an issue, then FIPS certification of any CAPWAP based system could become impossible. Your comments are appreciated, Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:34:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjZC-0001zU-Uq for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:34:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13749 for ; Wed, 28 Sep 2005 17:34:16 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D56120546; Wed, 28 Sep 2005 17:34:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3CDC420529; Wed, 28 Sep 2005 17:33:55 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58DB9204FD for ; Wed, 28 Sep 2005 17:32:24 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 1637B1FE16 for ; Wed, 28 Sep 2005 17:32:21 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2005 14:32:21 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208,217"; a="346480410:sNHT48712520" 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 j8SLWI4V017375 for ; Wed, 28 Sep 2005 14:32:18 -0700 (PDT) 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, 28 Sep 2005 14:32:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C474.1980CCCC" Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8B784@xmb-sjc-235.amer.cisco.com> Thread-Topic: Change Request 9.1.3.2. Mandatory and Optional Tunneling Modes Thread-Index: AcXEZnoe9MlS2WIHTWyQiQmRXCI+iA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Sep 2005 21:32:17.0375 (UTC) FILETIME=[198B7EF0:01C5C474] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Change Request 9.1.3.2. Mandatory and Optional Tunneling Modes Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:32:17 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C474.1980CCCC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All, =20 I would like to wait until we have come to some conclusion on 9.1.3.1 prior to making any recommendations. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C5C474.1980CCCC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
All,
 
I = would like to wait=20 until we have come to some conclusion on 9.1.3.1 prior to making any=20 recommendations.
 

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

 
------_=_NextPart_001_01C5C474.1980CCCC-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:34:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjZb-00027y-Ps for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:34:43 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13776 for ; Wed, 28 Sep 2005 17:34:39 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D5B7120548; Wed, 28 Sep 2005 17:34:39 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE3B420527; Wed, 28 Sep 2005 17:34:15 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC5F0204AF for ; Wed, 28 Sep 2005 17:32:25 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id E64DF2043D for ; Wed, 28 Sep 2005 17:32:22 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2005 14:32:22 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208"; a="346480419:sNHT31227796" 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 j8SLW34h017250 for ; Wed, 28 Sep 2005 14:32:20 -0700 (PDT) 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, 28 Sep 2005 14:32:15 -0700 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 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8B781@xmb-sjc-235.amer.cisco.com> Thread-Topic: Change Request 9.1.1. (Information Elements) Thread-Index: AcXEYXiF1GmGQGMJR1upPVz1zKYwOw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Sep 2005 21:32:15.0466 (UTC) FILETIME=[186834A0:01C5C474] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Change Request 9.1.1. (Information Elements) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:32:15 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable This change request is to expand the size of the type field in the message element header from 8 to 16 bits. The resulting change would change the following section and relevant text: 4.2.2 Message Element Format [...] The format of a message element uses the TLV format shown here: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... | +-+-+-+-+-+-+-+-+ Where Type (16 bit) identifies the character of the information carried in the Value field and Length (16 bits) indicates the number of bytes in the Value field. [...]=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:35:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjZy-0002CV-G7 for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:35:06 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13799 for ; Wed, 28 Sep 2005 17:35:03 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AEBCD2043D; Wed, 28 Sep 2005 17:35:02 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A5E6520510; Wed, 28 Sep 2005 17:34:34 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DEC812043D for ; Wed, 28 Sep 2005 17:32:26 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 390C3204F4 for ; Wed, 28 Sep 2005 17:32:24 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2005 14:32:22 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208"; a="346480422:sNHT32380256" 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 j8SLVxKU025532; Wed, 28 Sep 2005 14:32:18 -0700 (PDT) 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, 28 Sep 2005 14:32:14 -0700 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] CAPWAP evaluation draft complete Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8B77F@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcXC30ArKgYOgSkCQq6cJhzue2e0VgAGvE6AAB+1LSAAFvzfwAAcywaA From: "Pat Calhoun (pacalhou)" To: , "Darren Loher" , X-OriginalArrivalTime: 28 Sep 2005 21:32:14.0279 (UTC) FILETIME=[17B31570:01C5C474] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:32:14 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable > I understand your theory that starting with one of the drafts=20 > would have you believe it would speed up the process, but I=20 > do not agree or see how you can arrive at a conclusion that=20 > it would take "another year". =20 Of course the WG is free to take the direction it believes is right for the Internet Community, but my experience at IETF (13 years now) has proven to me that it is unrealistic to create a protocol from scratch in less than a year. In fact, RFC 3012 actually took well over a year from inception to RFC, and it is about as simple as an RFC can get - let alone a whole protocol. I won't even get into how long Diameter took, and it started from a base protocol (and, yes, we had plenty of interim meetings) ... Many additional examples available upon request... :) I think it is equally important to note that there is additional value in starting with a base draft, and ideally one that has been implemented and demonstrated that it works and solves the requirements. From my experience, up until a protocol has seen real world deployment, there are many gotchas that can go unnoticed during the specification phase.=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Troy Dixler > Sent: Tuesday, September 27, 2005 7:39 PM > To: 'Darren Loher'; capwap@frascone.com > Subject: RE: [Capwap] CAPWAP evaluation draft complete >=20 > > We did consider an approach of a new proposal with the best=20 > features=20 > > of all the good and interesting capabilities presented. =20 > However, as a=20 > > team we agreed this would be akin to "starting over" and=20 > would likely=20 > > extend the standards process by another year, if not=20 > longer. I am not=20 > > in favor of this, but it is up to working group consensus=20 > to decide if=20 > > a delay like that is desirable. >=20 >=20 > With the impending IPR claims as well as the fact that both=20 > protocols exhibit attributes that would benefit the working=20 > group I think we can turn it around rather quickly. The two=20 > drafts are simply not that complex. >=20 > I believe there have been a few voices that have responded to=20 > this thread stating that they would like to revisit the draft=20 > and define the attributes rather than one or the other for a=20 > base draft. I would equally be willing to work on the=20 > revised recommendation draft to define the core set of=20 > attributes that make up the CAPWAP standard. I believe=20 > others on the list would equally be willing to assist. >=20 > -Troy >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:35:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjaM-0002LK-0K for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:35:30 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13827 for ; Wed, 28 Sep 2005 17:35:27 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 191B520527; Wed, 28 Sep 2005 17:35:26 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52DC3204FD; Wed, 28 Sep 2005 17:34:52 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D28EA204AF for ; Wed, 28 Sep 2005 17:32:27 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id F159E1FE16 for ; Wed, 28 Sep 2005 17:32:24 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2005 14:32:24 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208,217"; a="346480446:sNHT66066752" 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 j8SLW34j017250 for ; Wed, 28 Sep 2005 14:32:22 -0700 (PDT) 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, 28 Sep 2005 14:32:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C474.19216EBC" Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8B783@xmb-sjc-235.amer.cisco.com> Thread-Topic: Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXEZkqBuwf+LMdnQ8KyHVKiUjMwyA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Sep 2005 21:32:16.0794 (UTC) FILETIME=[1932D7A0:01C5C474] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:32:16 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C474.19216EBC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. =20 The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled to the controller. =20 If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP =20 The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set of restrictions. For instance, today the LWAPP protocol allows for centralized control of various 802.11 functions, including encryption and 802.11e. This function is not possible with option 3, and therefore any new technology that assumes this option would not be able to provide centralization of data frame functions. =20 There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) that the WTP may want to extract and expose to the AC - and how could this be done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C5C474.19216EBC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
This = change request=20 is to allow for 802.3 tunneling of user data in local bridging mode. I = believe=20 that the changes should be relatively straightforward, but do introduce = an=20 interesting set of complications that need to be evaluated and agreed = upon as a=20 group.
 
The = LWAPP protocol=20 currently allows for 802.11 tunneling in Split-MAC mode, allowing for = such=20 things as centralized encryption of user data frames. However, the = current=20 definition of the protocol is that when running in Local-MAC mode, no = traffic is=20 tunneled to the controller.
 
If we = were to=20 introduce this change, the LWAPP protocol would have three modes of=20 operation:
1. = Split-MAC:=20 Tunnel native MAC frames in UDP (e.g., = 802.11)
2. = Local-MAC w/=20 Local Bridge: Do not tunnel 802.3 frames
3. = Local-MAC w/=20 Tunnel: Tunnel 802.3 frames in UDP
 
The = issue that we=20 need to decide as a group is whether we really want a protocol that has = three=20 modes of operation, and if so, which one is mandatory. The evaluation = draft=20 states that option 3 is useful for support of non 802.11 technologies, = but this=20 introduces a set of restrictions. For instance, today the LWAPP protocol = allows=20 for centralized control of various 802.11 functions, including=20 encryption and 802.11e. This function is not possible with option = 3, and=20 therefore any new technology that assumes this option would not be able = to=20 provide centralization of data frame functions.
 
There = is a comment=20 in the recommendation that LWAPP could retain the RSSI/SNR fields, and = then=20 perform 802.3 encapsulation, allowing the AC to have more visibility. = However, I=20 have had some requests to expand these fields to also include the data = rate.=20 Further, there are possible fields in the header (of technologies we = know=20 nothing about) that the WTP may want to extract and expose to the AC - = and how=20 could this be done with 802.3?

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

 
------_=_NextPart_001_01C5C474.19216EBC-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:35:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjac-0002YL-GC for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:35:46 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13841 for ; Wed, 28 Sep 2005 17:35:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1E1202054B; Wed, 28 Sep 2005 17:35:43 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 207D42053C; Wed, 28 Sep 2005 17:35:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05A641FE16 for ; Wed, 28 Sep 2005 17:32:29 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 3716E204BF for ; Wed, 28 Sep 2005 17:32:26 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2005 14:32:24 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208,217"; a="346480454:sNHT43531948" 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 j8SLVxKW025532 for ; Wed, 28 Sep 2005 14:32:20 -0700 (PDT) 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, 28 Sep 2005 14:32:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C474.19EE78F8" Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8B785@xmb-sjc-235.amer.cisco.com> Thread-Topic: Change Request 9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling Thread-Index: AcXEZqbpP0yIR3bZQYuB3PXUoDX/bg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Sep 2005 21:32:18.0122 (UTC) FILETIME=[19FD7AA0:01C5C474] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Change Request 9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:32:18 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C474.19EE78F8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I am ok with making the change to only allow LWAPP to operate over IP, but would like to get WG rough consensus on this topic before I make the necessary changes (which is really more of a cut than paste exercise). =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C5C474.19EE78F8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I am = ok with making=20 the change to only allow LWAPP to operate over IP, but would like to get = WG=20 rough consensus on this topic before I make the necessary changes (which = is=20 really more of a cut than paste exercise).
 

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

 
------_=_NextPart_001_01C5C474.19EE78F8-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:47:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjlh-0007Cp-7c for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:47:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14535 for ; Wed, 28 Sep 2005 17:47:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CC2D20510; Wed, 28 Sep 2005 17:47:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 735492043D; Wed, 28 Sep 2005 17:47:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 538582043D for ; Wed, 28 Sep 2005 17:46:51 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 3280A1FE16 for ; Wed, 28 Sep 2005 17:46:48 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2005 14:46:49 -0700 X-IronPort-AV: i="3.97,154,1125903600"; d="scan'208"; a="346484737:sNHT31184820" 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 j8SLkiKC002384 for ; Wed, 28 Sep 2005 14:46:44 -0700 (PDT) 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, 28 Sep 2005 14:46:45 -0700 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 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8B7AE@xmb-sjc-235.amer.cisco.com> Thread-Topic: Change Request 9.2.3. Data Encapsulation Standard Thread-Index: AcXEdh5Yz7SXc09kSfGDsz1466+ZwQ== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 28 Sep 2005 21:46:45.0714 (UTC) FILETIME=[1F1D8320:01C5C476] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Change Request 9.2.3. Data Encapsulation Standard Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:46:44 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable This optional change request is to make modifications to LWAPP to make use of the L2TP or GRE encapsulation protocols instead. The goal stated is re-use of code. =20 There are two alternatives proposed in this section, which is to make use of either GRE or L2TP with the goal of code re-use. While I agree that using GRE means one gets to re-use a GRE module, I believe the cons far outweigh the pros. Having been the person that pushed for the use of GRE in PPTP, I am very well aware of the issues this created in terms of NAT traversal. Basically, in order for PPTP to be NATed, every FW or NAT server had to implement the PPTP ALG in order to be able to extract the session identifier out of the control path, which is used to correlate the control and data path. Conversely, L2TP is NAT'ed for free because it is based on UDP.=20 Furthermore, even with GRE, we would still need to use the LWAPP header in order to exchange SNR/RSSI information. So, personally, I see GRE is being an alternative to UDP instead of being an alternative to LWAPP. Of course, there is then L2TP, but I would argue that LWAPP uses the same transport mechanism as L2TP, which is UDP. The evaluators state: "Using a standard gives the opprotunity for code reuse, whether it is off-the-shelf microcode for processors, code modules that can be purchased for real time operating systems, or open-source implementations for Unix based systems" There are a few issues with this. First, in unix based systems, most kernels modules have a 1:1 relationship with the control protocol. It is not clear to me how two daemons (l2tpd and lwappd) could configure L2TP tunnels. Further, given that we would have to define a new layer 2 specific subtype for L2TP, the current modules would have to be modified anyways. The new L2 subtype issue holds for microcode as well. In terms of purchasing source code, I would argue that data header parsing routines are generally not really worth paying the price of a full L2TP stack, because 85% of the code would not be re-usable (and the part that is useful would have to be re-worked). Therefore, I respectfully disagree with this recommendation. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:53:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjrW-0008Q9-4F for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:53:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14813 for ; Wed, 28 Sep 2005 17:53:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6697B2051F; Wed, 28 Sep 2005 17:53:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0AD872043D; Wed, 28 Sep 2005 17:53:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 190292043D for ; Wed, 28 Sep 2005 17:52:48 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id A06401FE16 for ; Wed, 28 Sep 2005 17:52:45 -0400 (EDT) Message-ID: <019301c5c476$f4f948d0$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pat Calhoun (pacalhou)" , References: <4FF84B0BC277FF45AA27FE969DD956A2B8B782@xmb-sjc-235.amer.cisco.com> Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:52:44 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit 2. Post-Discovery DTLS. In this mode, the above limitations are removed, and the Discovery phase is done in the clear. While it is true that this raises some security concerns, the information in the Discovery Response is relatively benign, and therefore any malicious tweaking (or altering) of the response packet has created limited damage (although the WG needs to evaluate this, but it was not found to be problematic during the security review). jak>> What was the security concern with doing discovery in the clear? jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:54:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjsT-0000Ae-8t for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:54:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14840 for ; Wed, 28 Sep 2005 17:54:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1234E20523; Wed, 28 Sep 2005 17:54:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A942A2043D; Wed, 28 Sep 2005 17:54:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4410420523 for ; Wed, 28 Sep 2005 17:53:26 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 31A9A20537 for ; Wed, 28 Sep 2005 17:53:18 -0400 (EDT) Message-ID: <019a01c5c477$08dfe390$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pat Calhoun (pacalhou)" , References: <4FF84B0BC277FF45AA27FE969DD956A2B8B781@xmb-sjc-235.amer.cisco.com> Subject: Re: [Capwap] Change Request 9.1.1. (Information Elements) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:53:17 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Sounds fine to me. jak ----- Original Message ----- From: "Pat Calhoun (pacalhou)" To: Sent: Wednesday, September 28, 2005 2:32 PM Subject: [Capwap] Change Request 9.1.1. (Information Elements) This change request is to expand the size of the type field in the message element header from 8 to 16 bits. The resulting change would change the following section and relevant text: 4.2.2 Message Element Format [...] The format of a message element uses the TLV format shown here: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... | +-+-+-+-+-+-+-+-+ Where Type (16 bit) identifies the character of the information carried in the Value field and Length (16 bits) indicates the number of bytes in the Value field. [...] Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:56:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjuP-0000vO-5k for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:56:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14952 for ; Wed, 28 Sep 2005 17:56:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B1A920510; Wed, 28 Sep 2005 17:56:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 66CE42041E; Wed, 28 Sep 2005 17:56:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD44B2043D for ; Wed, 28 Sep 2005 17:55:29 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 8B8741FE16 for ; Wed, 28 Sep 2005 17:55:27 -0400 (EDT) Message-ID: <01a701c5c477$556f7f90$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pat Calhoun (pacalhou)" , References: <4FF84B0BC277FF45AA27FE969DD956A2B8B785@xmb-sjc-235.amer.cisco.com> Subject: Re: [Capwap] Change Request 9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A4_01C5C43C.A9016550" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:55:26 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_01A4_01C5C43C.A9016550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Actually, I've been in favor of this for quite some time. So I agree. jak ----- Original Message -----=20 From: Pat Calhoun (pacalhou)=20 To: capwap@frascone.com=20 Sent: Wednesday, September 28, 2005 2:32 PM Subject: [Capwap] Change Request 9.2.2. Removal of Layer 2 = Encapsulation for Data Tunneling I am ok with making the change to only allow LWAPP to operate over IP, = but would like to get WG rough consensus on this topic before I make the = necessary changes (which is really more of a cut than paste exercise). Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------=_NextPart_000_01A4_01C5C43C.A9016550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Actually, I've been in favor of this for quite some = time. So I=20 agree.
 
        =    =20 jak
----- Original Message -----
From:=20 Pat = Calhoun=20 (pacalhou)
Sent: Wednesday, September 28, = 2005 2:32=20 PM
Subject: [Capwap] Change = Request 9.2.2.=20 Removal of Layer 2 Encapsulation for Data Tunneling

I am = ok with=20 making the change to only allow LWAPP to operate over IP, but would = like to=20 get WG rough consensus on this topic before I make the necessary = changes=20 (which is really more of a cut than paste = exercise).
 

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

 
------=_NextPart_000_01A4_01C5C43C.A9016550-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 17:59:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKjxL-00022X-3l for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 17:59:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15085 for ; Wed, 28 Sep 2005 17:59:11 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 250D820510; Wed, 28 Sep 2005 17:59:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6AC502041E; Wed, 28 Sep 2005 17:59:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2B3502041E for ; Wed, 28 Sep 2005 17:58:14 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 49A0A1FE16 for ; Wed, 28 Sep 2005 17:58:11 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j8SLppZM054399; Wed, 28 Sep 2005 14:51:51 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509282151.j8SLppZM054399@homebrew.trpz.com> To: "Darren Loher" Cc: troy@twisted.net, capwap@frascone.com Subject: Re: [Capwap] CAPWAP evaluation draft complete In-Reply-To: Your message of "Tue, 27 Sep 2005 09:10:21 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <54397.1127944311.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 14:51:51 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Darren, I understand the motivation in starting with a base draft but the thing is you're recommending to change the base of this base draft and that doesn't seem to be in line with the motivation in the first place. I question whether it really is a huge leap forward to proceed in this manner. Once again I would like to point out that the messaging of LWAPP-- which it looks like the evaluation team preferred-- could be a control type in SLAPP-- whose base it looks like the evaluation team preferred. If that was what that the WG started with I feel it would actually be faster to reach the resolution recommended by the evaluation team. This is because it's more complicated to change the tunneling and security of one of the protocols than it is to add/remove/modify TLVs. Dan. On Tue, 27 Sep 2005 09:10:21 PDT you wrote > > The evaluation team focused on the WG objectives for evaluating the > proposals. We elected to choose the base protocol which most fully > implemented the objectives. We chose a base protocol as a compromise to > help speed the delivery of a standard. The evaluation team believes > that LWAPP meets the objectives as defined better than any of the other > protocols. That is the basis for choosing LWAPP as a base protocol. > > Hopefully the WG can first consider if LWAPP is a suitable base > protocol. Obviously choosing a base protocol has a lot to do with > whatever changes we as a group think we're going to need to make to this > base. But if we can choose a base protocol, we will make a huge leap > forward in getting a real, working CAPWAP protocol defined. The team > thought this is the best approach for us to make progress as a working > group. > > We did consider an approach of a new proposal with the best features of > all the good and interesting capabilities presented. However, as a team > we agreed this would be akin to "starting over" and would likely extend > the standards process by another year, if not longer. I am not in favor > of this, but it is up to working group consensus to decide if a delay > like that is desirable. > > The additional recommendations are issues that the evaluation team would > like the working group to consider. We did not believe they are > required to meet the official WG objectives. However we strongly > believed that LWAPP would be a much better protocol if the "high > priority" recommendations were implemented in some way within LWAPP. > It's up to the working group at large to decide if these recommendations > are important enough to implement. > > > -Darren > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Troy Dixler > > Sent: Monday, September 26, 2005 6:30 PM > > To: capwap@frascone.com > > Subject: RE: [Capwap] CAPWAP evaluation draft complete > > > > I guess I'm not following the logic behind the recommendation. It > seems > > to > > me that rather than the group focusing in on what draft, they should > be > > focusing in on what attributes they want in the CAPWAP protocol. > There > > are > > clearly pieces of both base protocols that bring value to the working > > group. > > In the end the best pieces will become the basis we work from to > become a > > standard. > > > > To pick a "side" when clearly there were attributes that were not > within > > LWAPP just stirs up politics. > > > > Why not revise the draft to state the clear attributes and > recommendations > > that the protocol should contain and not start with either base draft > but > > start it fresh and call it by its rightful name CAPWAP. > > > > -Troy > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] > On > > > Behalf Of Wijnen, Bert (Bert) > > > Sent: Monday, September 26, 2005 4:01 PM > > > To: T. Charles Clancy; capwap@frascone.com > > > Subject: RE: [Capwap] CAPWAP evaluation draft complete > > > > > > Inline > > > > > > > -----Original Message----- > > > > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com]On > > > > Behalf Of T. Charles Clancy > > > > Sent: Monday, September 26, 2005 16:14 > > > > To: capwap@frascone.com > > > > Subject: RE: [Capwap] CAPWAP evaluation draft complete > > > > > > > > > > > > On Mon, 26 Sep 2005, Wijnen, Bert (Bert) wrote: > > > > > > > > > The evaluation team made a "decision" if you like for > > > > itself, but they > > > > > reported that decision as a RECOMMENDATION to the WG. > > > > > > > > Well if we don't take it as more than a RECOMMENDATION, I > > > > wonder what the point of an evaluation team was. > > > > > > > > > > I believe the value was en is that we had a dedicated team of people > > > who have meticoulously studied the objectives and the submission and > > > who have after that documented their findings precisely and at > > > then end even gave a recommendation. > > > > > > That is a very useful piece of input for the WG based on which they > > > can try to come to a decision as what to do. This in addition to any > > > other input (like your own evaluation etc). > > > > > > Bert > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 18:03:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKk1B-0002WP-4Q for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 18:03:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15222 for ; Wed, 28 Sep 2005 18:03:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A207F20526; Wed, 28 Sep 2005 18:03:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7707A204AF; Wed, 28 Sep 2005 18:03:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB3A5204AF for ; Wed, 28 Sep 2005 18:02:22 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 5A9C32041E for ; Wed, 28 Sep 2005 18:02:19 -0400 (EDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 28 Sep 2005 15:02:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8SM1vW9028569; Wed, 28 Sep 2005 15:02:11 -0700 (PDT) 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, 28 Sep 2005 15:02:14 -0700 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] Change Request 9.1.2 (Control Channel Security) Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8B7CF@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXEdyM7rR6iG2ecQSWDZ88/i9BPjwAAQdkg From: "Pat Calhoun (pacalhou)" To: "James Kempf" , X-OriginalArrivalTime: 28 Sep 2005 22:02:14.0959 (UTC) FILETIME=[48FD0BF0:01C5C478] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 15:02:14 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I am simply raising the point that it would be in the clear, with the understanding that the group should look at this deeper. However, this was not raised as an issue during the security evaluation of the protocol, and therefore I do not believe we have an issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > Sent: Wednesday, September 28, 2005 2:53 PM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) >=20 > 2. Post-Discovery DTLS. In this mode, the above limitations=20 > are removed, and the Discovery phase is done in the clear.=20 > While it is true that this raises some security concerns, the=20 > information in the Discovery Response is relatively benign,=20 > and therefore any malicious tweaking (or altering) of the=20 > response packet has created limited damage (although the WG=20 > needs to evaluate this, but it was not found to be=20 > problematic during the security review). >=20 >=20 > jak>> What was the security concern with doing discovery in the clear? >=20 > jak >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Sep 28 18:23:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKkKX-0007dL-Kw for capwap-archive@megatron.ietf.org; Wed, 28 Sep 2005 18:23:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17445 for ; Wed, 28 Sep 2005 18:23:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D6AB820510; Wed, 28 Sep 2005 18:23:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 344AC204AF; Wed, 28 Sep 2005 18:23:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65DD9204AF for ; Wed, 28 Sep 2005 18:22:57 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 7D1092041E for ; Wed, 28 Sep 2005 18:22:55 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j8SMGYKr054502; Wed, 28 Sep 2005 15:16:34 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200509282216.j8SMGYKr054502@homebrew.trpz.com> To: "Pat Calhoun (pacalhou)" Cc: capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) In-Reply-To: Your message of "Wed, 28 Sep 2005 14:32:16 PDT." <4FF84B0BC277FF45AA27FE969DD956A2B8B782@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <54500.1127945794.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 28 Sep 2005 15:16:34 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Pat, I agree that the information in the discovery phase is benign. Also, anything an attacker could do to at that point is the same as what an attacker could do during the DTLS "hello" exchange-- modify packets in flight, redirect packets-- and the result would be the same: an unsuccessful DTLS exchange or unsuccessful discovery. An attacker could deny service-- prevent a successful DTLS exchange or successful discovery of AC-- but any middlebox can start dropping packets on a whim and do the same thing. I don't believe there is a possibility of a resource exhaustion attack or launch a man-in-the-middle attack against the AC or WTP. I don't think we really need to worry about doing DTLS post-discovery. To address your call for wider WG response to this recommendation: I strongly believe that (D)TLS should be used for the key exchange and authentication protocol. My understanding on the reason that NIST preferred AES-KeyWrap over IPsec for the transporting of PMKs had nothing to do with any preceived weakness in IPsec. It was because there is nothing in the IPsec standard to allow a user-space app-- like a RADIUS client-- to know whether the packets it is sending are in the clear or are IPsec- protected. Therefore a mis-configuration could result in PMKs being sent over-the-wire in-the-clear. (There are IPsec implementations that do allow for such queries of the SADB but that isn't part of the IPsec standard and therefore there isn't a guarantee that such a capability will be available everywhere). Putting the security for passing the PMKs directly into the RADIUS app-- i.e. using AES-KeyWrap-- addresses that concern. Therefore I don't believe NIST would have a problem sending PTKs down a (D)TLS-protected link because the app that is sending and receiving them knows whether that link is protected or not. Dan. On Wed, 28 Sep 2005 14:32:16 PDT you wrote > The evaluation team has made a request to modify LWAPP's built-in > security mechanism with DTLS instead. This specific change is tricky as > we first need to identify whether the DTLS session should be created > prior to, or post, the discovery phase. > > Here are my high level thoughts on the issue: > 1. Pre-Discovery DTLS. > > One of the LWAPP features is load balancing of WTPs among ACs. This load > balancing can occur within, or across multiple, ACs. How this works is > that a WTP would perform the discovery phase by initiating a Discovery > Request packet to one or more ACs. The receiving ACs respond with a > Discovery Response, which also includes the total number of WTPs > supported (see section 5.2.2), as well as its current WTP load (see > section 5.2.3). The WTP collects all of the Discovery Responses, and > then decides which AC it wishes to connect to based on its policy. The > policy can be either least loaded AC, or through a list of preferred ACs > (see section 7.2.3). Further, the WTP can opt to not establish a session > with the AC if it determines that it does not have the basic > capabilities required by the AC. > > Performing DTLS prior to the Discovery Request would mean that the WTP > would mean one of two things: > a. The WTP establishes a DTLS session with every AC it knows about. The > side effect here is the LWAPP connect time on the WTP, not to mention > the CPU load imposed on the AC. > b. The LWAPP protocol eliminates this feature altogether. This means > that a WTP would only connect to the AC of its choice, regardless of the > AC's current load of configuration. > > 2. Post-Discovery DTLS. In this mode, the above limitations are removed, > and the Discovery phase is done in the clear. While it is true that this > raises some security concerns, the information in the Discovery Response > is relatively benign, and therefore any malicious tweaking (or altering) > of the response packet has created limited damage (although the WG needs > to evaluate this, but it was not found to be problematic during the > security review). > > This change would also require that the the Discovery packets be > exchanged on a separate UDP port, which is not a big change to the > protocol. > > while I understand the evaluation team's recommendation to adopt DTLS, I > would also like to get a larger WG rough consensus on whether we feel > that this change should be made. While I will make the change based on > rough consensus, I want to make sure that we think and agree on this > decision through as a group. I understand the concerns raised about > increasing the time of the protocol development phase in having our own > security approach, there are strategies that can be done to help us. For > instance, initiate another security review with another reviewer > identified by Russ Housely asap (he did recommend Charles Clancy, btw). > > I think that another important point here is that during a recent > meeting with NIST, we discussed the transport of 802.11i PMKs within the > RADIUS protocol. During this discussion, we proposed two methods. The > first would explicitely encrypt the PMK using AES-KeyWrap within a > RADIUS attribute. The second approach was simply to encrypt the whole > RADIUS transaction with IPSec. It was NIST's opinion at that time that > they felt comfortable with option one, while option two would require > them to evaluate whether IPSec would be appropriate for the transport of > PMKs. Given that CAPWAP has a requirement to allow the WTP to perform > encryption, this means that PTKs (and GTKs) would have to be transported > over a DTLS session, and therefore I wonder whether we would have > similar issues as those mentioned above. If this were an issue, then > FIPS certification of any CAPWAP based system could become impossible. > > Your comments are appreciated, > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Sep 29 11:55:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0kf-0008PX-7S for capwap-archive@megatron.ietf.org; Thu, 29 Sep 2005 11:55:22 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19923 for ; Thu, 29 Sep 2005 11:55:13 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61A612041A; Thu, 29 Sep 2005 11:55:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BD591FE0C; Thu, 29 Sep 2005 11:55:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90FB21FE0C for ; Thu, 29 Sep 2005 11:55:00 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 4674B1FDE9 for ; Thu, 29 Sep 2005 11:54:57 -0400 (EDT) Message-ID: <031901c5c50e$236b3650$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pat Calhoun (pacalhou)" , "Dan Harkins" Cc: References: <200509282216.j8SMGYKr054502@homebrew.trpz.com> Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 29 Sep 2005 08:54:56 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I agree with Dan. I think the risk from doing DTLS post-discovery is minimal. Security protocols have a history of bugs turning up after some years of deployment. An added benefit of using DTLS is that LWAPP benefits from the attention given to DTLS by users of other protocols, so any bugs will most likely be found more quickly than if LWAPP designs its own, specialized protocol. Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute for PMK distribution, I don't have any real opinion on this. Actually, I think I would prefer to leave this as a deployment option, with appropriate text in the Security Considerations section about the requirement to use one of these method, and the methods are described. I realize that there is an interoperability concern here, but I can imagine cases where a network operator might prefer one method over another due to their existing deployment. As Dan mentioned, the concerns expressed about using IPsec related to particular implementation issues rather than any fundamental architectural or design issue with the protocol. But I don't have a real strong opinion on this, and I can think of reasons why it might be a good idea to include a particular "required to implement" method too. jak ----- Original Message ----- From: "Dan Harkins" To: "Pat Calhoun (pacalhou)" Cc: Sent: Wednesday, September 28, 2005 3:16 PM Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > Pat, > > I agree that the information in the discovery phase is benign. Also, > anything an attacker could do to at that point is the same as what an > attacker could do during the DTLS "hello" exchange-- modify packets > in flight, redirect packets-- and the result would be the same: an > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > could deny service-- prevent a successful DTLS exchange or successful > discovery of AC-- but any middlebox can start dropping packets on a > whim and do the same thing. I don't believe there is a possibility of > a resource exhaustion attack or launch a man-in-the-middle attack > against the AC or WTP. > > I don't think we really need to worry about doing DTLS post-discovery. > > To address your call for wider WG response to this recommendation: > I strongly believe that (D)TLS should be used for the key exchange and > authentication protocol. > > My understanding on the reason that NIST preferred AES-KeyWrap over > IPsec for the transporting of PMKs had nothing to do with any > preceived weakness in IPsec. It was because there is nothing in the > IPsec standard to allow a user-space app-- like a RADIUS client-- to > know whether the packets it is sending are in the clear or are IPsec- > protected. Therefore a mis-configuration could result in PMKs being > sent over-the-wire in-the-clear. (There are IPsec implementations that > do allow for such queries of the SADB but that isn't part of the IPsec > standard and therefore there isn't a guarantee that such a capability > will be available everywhere). Putting the security for passing the > PMKs directly into the RADIUS app-- i.e. using AES-KeyWrap-- addresses > that concern. Therefore I don't believe NIST would have a problem sending > PTKs down a (D)TLS-protected link because the app that is sending and > receiving them knows whether that link is protected or not. > > Dan. > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote >> The evaluation team has made a request to modify LWAPP's built-in >> security mechanism with DTLS instead. This specific change is tricky as >> we first need to identify whether the DTLS session should be created >> prior to, or post, the discovery phase. >> >> Here are my high level thoughts on the issue: >> 1. Pre-Discovery DTLS. >> >> One of the LWAPP features is load balancing of WTPs among ACs. This load >> balancing can occur within, or across multiple, ACs. How this works is >> that a WTP would perform the discovery phase by initiating a Discovery >> Request packet to one or more ACs. The receiving ACs respond with a >> Discovery Response, which also includes the total number of WTPs >> supported (see section 5.2.2), as well as its current WTP load (see >> section 5.2.3). The WTP collects all of the Discovery Responses, and >> then decides which AC it wishes to connect to based on its policy. The >> policy can be either least loaded AC, or through a list of preferred ACs >> (see section 7.2.3). Further, the WTP can opt to not establish a session >> with the AC if it determines that it does not have the basic >> capabilities required by the AC. >> >> Performing DTLS prior to the Discovery Request would mean that the WTP >> would mean one of two things: >> a. The WTP establishes a DTLS session with every AC it knows about. The >> side effect here is the LWAPP connect time on the WTP, not to mention >> the CPU load imposed on the AC. >> b. The LWAPP protocol eliminates this feature altogether. This means >> that a WTP would only connect to the AC of its choice, regardless of the >> AC's current load of configuration. >> >> 2. Post-Discovery DTLS. In this mode, the above limitations are removed, >> and the Discovery phase is done in the clear. While it is true that this >> raises some security concerns, the information in the Discovery Response >> is relatively benign, and therefore any malicious tweaking (or altering) >> of the response packet has created limited damage (although the WG needs >> to evaluate this, but it was not found to be problematic during the >> security review). >> >> This change would also require that the the Discovery packets be >> exchanged on a separate UDP port, which is not a big change to the >> protocol. >> >> while I understand the evaluation team's recommendation to adopt DTLS, I >> would also like to get a larger WG rough consensus on whether we feel >> that this change should be made. While I will make the change based on >> rough consensus, I want to make sure that we think and agree on this >> decision through as a group. I understand the concerns raised about >> increasing the time of the protocol development phase in having our own >> security approach, there are strategies that can be done to help us. For >> instance, initiate another security review with another reviewer >> identified by Russ Housely asap (he did recommend Charles Clancy, btw). >> >> I think that another important point here is that during a recent >> meeting with NIST, we discussed the transport of 802.11i PMKs within the >> RADIUS protocol. During this discussion, we proposed two methods. The >> first would explicitely encrypt the PMK using AES-KeyWrap within a >> RADIUS attribute. The second approach was simply to encrypt the whole >> RADIUS transaction with IPSec. It was NIST's opinion at that time that >> they felt comfortable with option one, while option two would require >> them to evaluate whether IPSec would be appropriate for the transport of >> PMKs. Given that CAPWAP has a requirement to allow the WTP to perform >> encryption, this means that PTKs (and GTKs) would have to be transported >> over a DTLS session, and therefore I wonder whether we would have >> similar issues as those mentioned above. If this were an issue, then >> FIPS certification of any CAPWAP based system could become impossible. >> >> Your comments are appreciated, >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap >> > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap