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

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Mon, 22 Aug 2005 16:15:28 -0700

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

---

From: Dan Harkins <[email-masked]>
Date: Wed, 24 Aug 2005 10:59:57 -0700

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