Subject: RE: [Capwap] Expanded discussion on regulatory certification

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Tue, 30 Aug 2005 22:40:32 -0700

Dan,

If I understand the driver that you reference, it has a firmware component that is created by Cisco embedded within it (cribbed by reverse engineering the Cisco driver and extracting the binary that is downloaded to the microcoded processor on the card).  It is this portion of the driver that controls any portion 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-compliant 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 microcode 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 things 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:[email-masked]] 
Sent: Tuesday, August 30, 2005 8:13 PM
To: Bob O'Hara (boohara)
Cc: [email-masked]
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 has
> control of radio parameters, such as transmit power, frequency of operation, 
>and spectral shape of the transmitted waveform, onto an AP/WTP (which the FCC 
>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, certa
>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.  Dow
>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 signal 
>that is above that allowed by its certification, causing illegal interference 
>in the adjacent band.
> 
> The difference is very important.  It is also very important that this discus
>sion continue in this forum, as there are very few, if any IETF documents that
> directly affect whether a device is legal to operate under governmental emiss
>ions regulations.  This might be the first time that the IETF has had to consi
>der this issue.  I believe that many here do not yet understand the importance
> of the issue.
> 
> But, back to our discussion.
> 
> You say that it is possible to download code to an AP/WTP that "would retain 
>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 third
> 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 party 
>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 autho
>rization of the manufacturer.  Downloading code that causes access to the regi
>sters of a chip, for example, that has control of the RF transmission characte
>ristics of the certified device is modifying the device.
> 
> Here are additional citations from the regulations governing the certificatio
>n of radio frequency equipment in the United States, supporting this position.
> 
> 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 authoriza
>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 author
>ization of the grantee pursuant to § 2.929(b), the party performing the modific
>ation is responsible for compliance of the product with the applicable adminis
>trative and technical provisions in this chapter.
> 
> 47CFR2.909 (d) states the following:
> (d) If, because of modifications performed subsequent to authorization, a new
> party becomes responsible for ensuring that a product complies with the techn
>ical standards and the new party does not obtain a new equipment authorization
>, the equipment shall be labelled, following the specifications in § 2.925(d), 
>with the following: ''This product has been modified by [insert name, address 
>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 cod
>e developer, the AC vendor that performs the unauthorized (by the original equ
>ipment manufacturer) download to the WTP, or possibly the customer that entere
>d the command to perform the download is now the party responsible for the cer
>tification/authorization of the  WTP, not the original manufacturer.  At a min
>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, the
> device is now the responsibility of someone other than the original manufactu
>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 the
> original manufacturer of the WTP, the following definition is provided by the
> FCC 47CFR2.908:
> 
> 2.908 Identical defined.
> As used in this subpart, the term identical means identical within the variat
>ion that can be expected to arise as a result of quantity production technique
>s.
> 
> This definition does not encompass a third party changing the code operating 
>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:[email-masked]] 
> Sent: Wednesday, August 24, 2005 11:00 AM
> To: Bob O'Hara (boohara)
> Cc: [email-masked]
> 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 of 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:[email-masked]] 
> > Sent: Monday, August 22, 2005 1:59 PM
> > To: Bob O'Hara (boohara)
> > Cc: [email-masked]
> > 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:[email-masked]] 
> > > Sent: Wednesday, August 17, 2005 4:24 PM
> > > To: Bob O'Hara (boohara)
> > > Cc: [email-masked]
> > > 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:[email-masked]] 
> > > > Sent: Wednesday, August 03, 2005 3:29 AM
> > > > To: Bob O'Hara (boohara)
> > > > Cc: [email-masked]
> > > > 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
> > > > > [email-masked]
> > > > > http://mail.frascone.com/mailman/listinfo/capwap
> > > > > 
> > > > _______________________________________________
> > > > Capwap mailing list
> > > > [email-masked]
> > > > http://mail.frascone.com/mailman/listinfo/capwap
> > > > 
> > > _______________________________________________
> > > Capwap mailing list
> > > [email-masked]
> > > http://mail.frascone.com/mailman/listinfo/capwap
> > > 
> > _______________________________________________
> > Capwap mailing list
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/capwap
> > 
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Dan Harkins <[email-masked]>
Date: Tue, 30 Aug 2005 22:42:46 -0700

Bob,

  There's an atheros driver too that has explicit txpower parameters
passed to a HAL routine to transmit a packet. Mucking with that
parameter would make it 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-compliant 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
>