Capwap Mailing List: RE: Expanded discussion on regulatory certification

[Bob O'Hara (boohara) (boohara]

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.  

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
 
-----Original Message-----
From: Dan Harkins [mailto:dharkins [at] trpz.com] 
Sent: Thursday, September 01, 2005 12:48 PM
To: David Case (davecase)
Cc: Bob O'Hara (boohara); capwap [at] frascone.com
Subject: Re: [Capwap] Expanded discussion on regulatory certification 

  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 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.
> 
> 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
> 
> 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 approvals
>.
> 
> 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 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.
> 
> If a 3rd party wants to change it then under FCC rules they need to label it 
>as being modified and list themselves as the responsible party. 
> 
> Our manuals state that any unauthorized changes could put the user at risk 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 [at] frascone.com [mailto:capwap-admin [at] frascone.com] 
> On Behalf 
>Of Dan Harkins
> Sent: Wednesday, August 31, 2005 1:43 AM
> To: Bob O'Hara (boohara)
> Cc: capwap [at] frascone.com
> Subject: Re: [Capwap] Expanded discussion on regulatory certification 
> 
>   Bob,
> 
>   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. 
> 
>   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 non-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 [at] trpz.com]
> > Sent: Tuesday, August 30, 2005 8:13 PM
> > To: Bob O'Hara (boohara)
> > Cc: capwap [at] 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 § 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 § 
> > >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:
> > > § 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 [at] trpz.com]
> > > Sent: Wednesday, August 24, 2005 11:00 AM
> > > To: Bob O'Hara (boohara)
> > > Cc: capwap [at] 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 box.
> > > 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 certification.
> > > 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 manufacturer 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 [at] trpz.com]
> > > > Sent: Monday, August 22, 2005 1:59 PM
> > > > To: Bob O'Hara (boohara)
> > > > Cc: capwap [at] 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 advisor 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 FUD".
> > > > > 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 future. 
> 
> > > > > 
> > > > > 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 APs.
> > > > 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 curtain"
> > > > and
> > > > > believe that you are living in Oz.  But, in actuality, you are
> > > > dreaming.
> > > > > 
> > > > >  -Bob
> > > > >  
> > > > > -----Original Message-----
> > > > > From: Dan Harkins [mailto:dharkins [at] trpz.com]
> > > > > Sent: Wednesday, August 17, 2005 4:24 PM
> > > > > To: Bob O'Hara (boohara)
> > > > > Cc: capwap [at] 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.
> > > > > > </802.11 Technical advisor to CAPWAP hat>
> > > > > > 
> > > > > > 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 [at] trpz.com]
> > > > > > Sent: Wednesday, August 03, 2005 3:29 AM
> > > > > > To: Bob O'Hara (boohara)
> > > > > > Cc: capwap [at] 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 CAPWAP
>.
> > > > 
> > > > > > 
> > > > > >   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 participants.
> > > > > > > 
> > > > > > > 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 [at] frascone.com
> > > > > > > http://mail.frascone.com/mailman/listinfo/capwap
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Capwap mailing list
> > > > > > Capwap [at] frascone.com
> > > > > > http://mail.frascone.com/mailman/listinfo/capwap
> > > > > > 
> > > > > _______________________________________________
> > > > > Capwap mailing list
> > > > > Capwap [at] frascone.com
> > > > > http://mail.frascone.com/mailman/listinfo/capwap
> > > > > 
> > > > _______________________________________________
> > > > Capwap mailing list
> > > > Capwap [at] frascone.com
> > > > http://mail.frascone.com/mailman/listinfo/capwap
> > > > 
> > > _______________________________________________
> > > Capwap mailing list
> > > Capwap [at] frascone.com
> > > http://mail.frascone.com/mailman/listinfo/capwap
> > > 
> > _______________________________________________
> > Capwap mailing list
> > Capwap [at] frascone.com
> > http://mail.frascone.com/mailman/listinfo/capwap
> > 
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/capwap
>