Capwap Mailing List: RE: Expanded discussion on regulatory certification

[Bob O'Hara (boohara) (boohara]

Dan,

Your example of loading a different OS onto a PC (which is an unintentional 
radiator 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, certain 
code loops can be created to sing a song on a nearby radio.  But, this is still 
within the requirements under which the PC was originally certified.  
Downloading 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 
discussion 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 
emissions regulations.  This might be the first time that the IETF has had to 
consider 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 
disagree.  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 manner.  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 it. 
 It is not transferable or modifiable by anyone else, without express 
authorization of the manufacturer.  Downloading code that causes access to the 
registers of a chip, for example, that has control of the RF transmission 
characteristics of the certified device is modifying the device.

Here are additional citations from the regulations governing the certification 
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 
equipment 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 authorization 
is issued (the grantee) If the radio frequency equipment is modified by any 
party other than the grantee and that party is not working under the 
authorization of the grantee pursuant to § 2.929(b), the party performing the 
modification is responsible for compliance of the product with the applicable 
administrative 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 
technical 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 code 
developer, the AC vendor that performs the unauthorized (by the original 
equipment manufacturer) download to the WTP, or possibly the customer that 
entered the command to perform the download is now the party responsible for 
the certification/authorization of the  WTP, not the original manufacturer.  At 
a minimum, 47CFR2.909 (d) will require someone to physically access each 
modified WTP to affix a sticker.  Even without actually certifying the modified 
WTP, the device is now the responsibility of someone other than the original 
manufacturer 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 
variation that can be expected to arise as a result of quantity production 
techniques.

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 can 
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 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: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
>