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

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Fri, 2 Sep 2005 13:15:10 -0700

Dan,

To further expand upon your discussion of determination of responsibility for compliance, as you mention in your first paragraph, below, I quote from the Trapeze document entitled "Trapeze Regulatory Information", Part Number: 730-9502-0017, Revision C.

"The manufacturer, Trapeze Networks, is not responsible for any interference caused by unauthorized modification of the devices included with this product, or the substitution or attachment of connecting cables or equipment other than supplied by Trapeze Networks.

The correction of interference caused by such unauthorized modification, substitution, or attachment is your responsibility.

Trapeze Networks and its authorized resellers or distributors are not liable for any damage or violation of government regulations that might arise from failure to comply with these guidelines."

It appears that Trapeze has a very similar interpretation of the regulations to that of Cisco, from this statement.  Can you tell me how this statement differs from the position of Cisco on the topic?

Again, the issue is not compliance with emissions regulations when downloading unauthorized third party code.  We both concede that such third party code has the possibility of keeping a modified device in compliance with those regulations.  The issues are responsibility for that emissions compliance after the download has taken place and compliance with the further regulations requiring that each such modified device must be labeled as I described in my earlier, as yet still unanswered, email.

Both the SLAPP and LWAPP protocol proposals include the ability to download code to an AP/WTP.  The difference between the two is that CAPWAP requires an authentication signature must be validated before a download can be used, while SLAPP has no such mechanism and specifically allows download of code from sources other than the manufacturer or an authorized delegate of the manufacturer.  This is a significant difference between the two protocols and needs to be considered when evaluating the protocols during this phase of selecting the basis for CAPWAP standardization.

Going back to one of my first statements on this topic and to bring this around again to why this discussion is important to the working group while evaluating protocols, independent implementations of LWAPP can be built from the protocol specification, alone.  That same statement cannot be made about SLAPP.  

In order for a WTP to be operational after SLAPP downloads code from an unauthorized third party onto that WTP, there must be additional knowledge that is known to the third party that creates the download image.  That additional information is not conveyed by SLAPP, e.g., memory size, I/O port addresses, time constants, etc. that are dependent on the hardware design of the WTP.  That information can be gained only through communication between the manufacturer of the WTP and the third party, outside of the SLAPP protocol.  That communication might be in the context of a business relationship with a vendor from whom the WTP manufacturer purchased a design, reverse engineering of the WTP by the third party, or some other means.  But, in order for SLAPP to perform the functions required by CAPWAP, that outside communication is required.

The reason this outside communication is not required for LWAPP is that there is no third party.  There is only the AC vendor and the WTP vendor.  The only image that the WTP will accept from the AC under the LWAPP protocol is an image that is authenticated by the WTP vendor.  From that point forward, the AC and WTP communications is completely defined by the LWAPP protocol.  There is no need for any additional protocol buried within the downloaded image to obtain a fully functional WTP.

 -Bob
 
-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Thursday, September 01, 2005 12:48 PM
To: David Case (davecase)
Cc: Bob O'Hara (boohara); [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf 
>Of Dan Harkins
> Sent: Wednesday, August 31, 2005 1:43 AM
> To: Bob O'Hara (boohara)
> Cc: [email-masked]
> 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:[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 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:[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 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:[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
> > 
> _______________________________________________
> 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: "David T. Perkins" <[email-masked]>
Date: Fri, 2 Sep 2005 16:28:27 -0700 (PDT)

HI,

<here is the short version without all the history, since with
the history it was over 40K and is being held waiting for
list moderator approval.>

HI,

So it seems to me the issue is the following....

Should the CAPWAP protocol be restricted in what it can do by
the manufacturer of the equipment (in this case the WTP), or
should it allow the user (owner) of the equipment to decide.
Note that it is an agreed requirement that CAPWAP has the
security features so that operations can be restricted to
authorized users.

This, essentially the same, issue comes up all the time in
network/device management. That is, should some how the
management protocol restrict the configuration or action
to "proper" values or actions. Where "proper" might mean
"so it will do some useful work", "so it will not self destruct",
"so it will not cause harm to others", etc.

RFCs now have "a security considerations" section so to
bring to the light deployment issues.

So, in the end, I believe it is up to the owner of equipment
to make proper choices (and be responsible for those choices),
and not up to protocol developers to decide what is right or wrong.
Or to put it another way... If the protocol makes it "darn
near impossible" to do something, but over time a legitimate
reason comes up, the work around of the protocol prohibitation
is usually pretty expensive.

Regards,
/david t. perkins

---

From: Dan Harkins <[email-masked]>
Date: Fri, 02 Sep 2005 22:52:46 -0700

Bob,

On Fri, 02 Sep 2005 13:15:10 PDT you wrote
[snip]
> 
> Both the SLAPP and LWAPP protocol proposals include the ability to download c
>ode to an AP/WTP.  The difference between the two is that CAPWAP requires an a
>uthentication signature must be validated before a download can be used, while
> SLAPP has no such mechanism and specifically allows download of code from sou
>rces other than the manufacturer or an authorized delegate of the manufacturer
>.  This is a significant difference between the two protocols and needs to be 
>considered when evaluating the protocols during this phase of selecting the ba
>sis for CAPWAP standardization.

"Both the SLAPP and LWAPP protocol proposals.... The difference between the
two is that CAPWAP requires an authentication signature must be validated
before a download can be used, while SLAPP has no such mechanism...."

LWAPP = CAPWAP? I think you're getting a little excited here Bob. Either
that or you know something that has not been made public yet.

What you don't know is how SLAPP works. Please go read the spec. There is
an authentication step PRIOR to the AC and WTP deciding whether to proceed
to the full-fledged control and provisioning protocol or to do image download.

> Going back to one of my first statements on this topic and to bring this arou
>nd again to why this discussion is important to the working group while evalua
>ting protocols, independent implementations of LWAPP can be built from the pro
>tocol specification, alone.  That same statement cannot be made about SLAPP.  

Wrong! SLAPP includes a complete provisioning and control protocol. 

  Dan.

---

From: "Troy Dixler" <[email-masked]>
Date: Sat, 3 Sep 2005 08:28:56 -0500

Guys,

I've been watching the argument on this thread and feel that it's time to
make a statement as a working group member.  There are two very separate
arguments going on here.  One is related to IPR claims and the other around
image download and FCC violations.  I am not making this comment around the
image download portion but believe it's essential to discuss the IPR issue.

I've seen the IPR game getting out of hand within the IETF for way too long.
There are way too many drafts that are coming into the IETF standards
process claiming IPR.  

The purpose for the CAPWAP working group is to create an OPEN standard that
all vendors can implement and show interoperability.  Regardless of the
image download argument, before I'll stand up and back the LWAPP or SLAPP
contribution, I want Cisco as well as Trapeze to remove any notion of owing
IPR where they can go after other vendors that implement an IETF standard.
That simply does not wash.  

If the IPR comment stands then we as a working group must engineer around
any/all requirements and come up with a standard that does not allow one
vendor to have that type of power.  

I do not buy into any comments such as "we would never do it" or "we want to
contribute to this moving forward" etc. If that is the case, drop the IPR
claim and then we can go back to considering what protocol would best
represent the basis for CAPWAP.

The notion of trying to move on from this topic and even consider using a
protocol that has this type of IPR claim is ridiculous (IMHO).  I want an
IPR free protocol standard out of this group.

So there are two questions.  Will both the main authors of each of the specs
remove any/all IPR claims for consideration of being in the spec? It's a
simple question of yes or no. Please do not present a long reply without
answering it as a binary decision.

-Troy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dan Harkins
> Sent: Saturday, September 03, 2005 12:53 AM
> To: Bob O'Hara (boohara)
> Cc: [email-masked]

---

From: Dan Harkins <[email-masked]>
Date: Sat, 03 Sep 2005 09:46:56 -0700

Troy,

  There is no IPR claim on SLAPP to remove. 

  Dan.

On Sat, 03 Sep 2005 08:28:56 CDT you wrote

---

From: Partha Narasimhan <[email-masked]>
Date: Sat, 03 Sep 2005 11:20:15 -0700

I concur with Dan regarding IPR and SLAPP. Our goal was to come up with 
a proposal that re-used existing protocols as much as possible resulting 
in a simple, yet complete proposal.
Thanks
partha

Dan Harkins wrote:

>>>>Both the SLAPP and LWAPP protocol proposals include the ability to
>>>>        
>>>>
>>>download c
>>>      
>>>
>>>>ode to an AP/WTP.  The difference between the two is that CAPWAP requires
>>>>        
>>>>
>>>an a
>>>      
>>>
>>>>uthentication signature must be validated before a download can be used,
>>>>        
>>>>
>>>while
>>>      
>>>
>>>>SLAPP has no such mechanism and specifically allows download of code
>>>>        
>>>>
>>>from sou
>>>      
>>>
>>>>rces other than the manufacturer or an authorized delegate of the
>>>>        
>>>>
>>>manufacturer
>>>      
>>>
>>>>.  This is a significant difference between the two protocols and needs
>>>>        
>>>>
>>>to be
>>>      
>>>
>>>>considered when evaluating the protocols during this phase of selecting
>>>>        
>>>>
>>>the ba
>>>      
>>>
>>>>Going back to one of my first statements on this topic and to bring this
>>>>        
>>>>
>>>arou
>>>      
>>>
>>>>nd again to why this discussion is important to the working group while
>>>>        
>>>>
>>>evalua
>>>      
>>>
>>>>ting protocols, independent implementations of LWAPP can be built from
>>>>        
>>>>
>>>the pro
>>>      
>>>
>>>>tocol specification, alone.  That same statement cannot be made about
>>>>        
>>>>
>>>SLAPP.
>>>