Comment:

The requirement that Remote ID transmissions can be received and decoded by mobile devices dates back to the FAA UAS ID and Tracking Aviation Rulemaking Commitee (ARC) in 2017. At the time, law enforcement and homeland defense agencies were deeply concerned about "rogue" drones, and the FAA refused to allow advanced operations (i.e operations near and over people). At the time a future was imagined where people could use their smartphone to identify a drone they saw in the sky.  This led to requirements that effectively limited Broadcast Remote ID to using either Wifi or Bluetooth protocols on the unregulated 2.4GHz spectrum. This decision has led to the severe limitations of broadcast Remote ID that are acknowledged in this section of the NPA. This requirement prevents Broadcast Remote ID from having any useful role in a long term, robust RTM. Mandating broadcast Remote ID based on the ASTM F3411 standard places a large technological burden on RPAS pilots without providing a path towards integration within a future-proof RTM system. 

 In the almost 10 years since the ARC made its recommendations, the RPAS technology has evolved, and public acceptance of RPAS operations has increased. Unlike the FAA, Canada also implemented Advanced RPAS operations in 2019 without a requirement for Remote ID. Basing a future RTM on an decision made by a 2017 Airspace Rulemaking Commitee ignores the advancement and development in the RPAS community that has occurred over the last 10 years. 

Comment:

It was stated earlier that the intent of Remote ID is to support the management of BVLOS and more Complex RPAS operations. Presumably a major element of this support will be flight path management, which is fundamental to collision avoidance and safe operation. This section of the NPA ackowledges that Broadcast Remote ID (as proposed here) does not have the performance to allow RPAS to detect other RPAS. In addition to the privacy and security issues mentioned elsewhere, this proposal would place a large technical and financial burden on VLOS operators without the while not directly supporting the main stated goal of Remote ID, which is to support the safe integration of RPAS operations into the Canadian National Airspace.  

Comment:

There are absolutely some positive elements of the US recreational aircraft model that would alleviate some of the burden on the model aircraft community flying at fixed flying sites. 

Transport Canda should endeavour to address the lessons learnt by the FAA through during the development of their recreational model and FRIA site process. The Canadian CBO framework could be very helpful to the model aircraft community that has had a great deal of difficulty adjusting to operations within the Part IX regulations. Some of the elements that should be incorporated and issues that should be addressed are discussed elsewhere in these comments. 

Comment:

As explained elsewhere in these comments, please do not mandate Remote ID for Basic or Advanced Operations. 

This is placing an technological and financial burden on RPAS pilots who are performing simple operations, and who have demonstrated over almost a decade of operation under CAR Part IX that they can safely and responsibly operate without the need to publicly broadcast their identification and position over Bluetooth or Wifi.

Remote ID, or more realistically a bespoke RPAS Traffic Management System does have a role in the growth and safe operation of highly automated BVLOS operations. As acknowledged elsewhere in this proposal, these complex operations will not be directly supported by the mandate for Broadcast Remote ID on Basic and Advanced VLOS operations. The move to require Broadcast Remote ID was ill advised when it was recommended by the FAA ARC in 2017, and the both the RPAS community as well as the counter-RPAS technology has moved beyond the need for remote ID.  

*** To be deleted/moved ***

As discussed above, while Remote ID might catch the "Careless" and 

It is true that "clueless" operators often operate their RPA in areas where they pose a hazard to people on the ground or aircraft in the air. 

However, the clueless nature of these operators means that they generally do not take meausures to hide themselves. If these operators are truly creating a hazard, they can easily be tracked down by authorities who can follow the RPAS back to where it lands and generally meet the RPAS pilot there and take either educational or corrective measures to ensure that safety is ensured.

"Criminal" operators, or ones who are intentionally creating a hazard to people and aricraft, or are intentionally using their RPA for some kind of illegal activity. cannot be expected to abide by Remote ID mandates. They will either build or purchase non compliant RPAS, or they will disable the Remote ID transmission function on their RPAS. 

Mandating remote ID on law-abiding RPAS pilots will not do anything to reduce the risk from operators who intentionally violate Part IX rules.

Comment:

Talk about how this would be fine for a highly integrated commercial product. The rule is written for the DJI of the world. 

it is much more difficult to add a broadcast module to a home built RC plane, and it doesn't make sense for supporting any of the issues that Remote ID is purported to solve. 

talk about the EMI issue with several transmitters on an  aircraft? 

Broadcast modules don't have a safe or easy way of alerting the pilot during flight that they have ceased to function. This technical integration is a large burden on VLOS RPAS pilots, especially those who are members of the model aircraft community. 

Comment:

For Remote ID to function as described in this paper, a framework based on "Performance Based Requirements" will not work. If ASTM F3411 is seen as one of many means of meeting the Remote ID requirement, then there is no guarantee that Remote ID transmissions can be received and decoded by third parties. 

CAR standard 922 is intentionally written as a "Performance Based" standard. As mentioned above this means that it specifically says "what" an RPAS designer needs to do, but not the "how". As written today, CAR Standard 922 is technology agnostic and only states the performance goal (i.e. Design a safe drone). The Canadian Drone industry has long appreciated this type of safety standard as it allows for innovation and rapid product development. 

An example of this at work is CAR Standard 922.04, Operations in Controlled Airspace. CAR Standard 922.04 states that the RPAS must indicate to the pilot the aircraft location to within 10m horizontally and 16m vertically. While most RPAS manufacturers use GPS to accomplish this task, manufacturers are free to use other means to meet the localization standard. I, personally, have declared to Transport Canada that I meet Standard CAR 922.04 by operating VLOS (I can see my aircraft and therefore I know where it is to within the required accuracy). This declaration has been audited by Transport Canada and found to meet the spirit of the standard. 

If the "what" of a performance based Remote ID standard is to "transmit data related to the aircraft and flight", then manufacturers would not only be limited to using ASTM Standard F3411 and the Bluetooth or Wifi protocols that it specifies. Having a performance-based Remote ID standard as described here would leave the door open for manufacturers to develop their own means and methods of transmitting the required data. (i.e. Tom's Basement Morse Code based Remote-ID, placing a giant screen next to the operator with the required data displayed on it, using a banner or a loudspeaker to broadcast the required information). Clearly  this would not assist the stated goals of supporting RPAS traffic integration, safety and security. 

For Remote ID to function as described in this proposal, this performance based method would not work. Transport Canada will need to be prescriptive in how Remote ID requirements are met if the intent is that remote ID broadcasts can be decoded by third party aps on mobile devices.

Comment: 

What about homemade broadcast modules that do not have a serial number?

When I registered my home-built model aircraft, I assigned it serial number "001".  Will I be required to go back into the DMP to change this number to the serial number of a broadcast Remote ID module? How will TC monitor that this has been done? 

What about control stations that do not support GPS or altitude localization of the control station?

What about RPA that do not include GPS or altitude sensors?

Comment:

Not all RPAS operators purchase new RPA on a schedule, and many hobbyists do not purchase ready-to-fly RPA. A significant part of the model aircraft hobby is in building and reusing parts to experiment with new designs and build new aicraft. These hobbyists would be required to purchase add on modules to equip their fleet. These modules typically cost at least $100 which can become a significant expense considering the cost of other parts of the aircraft. 

I personally have model aircraft that were built in 2005, and are still in active use. I also have a significant amount of RPAS equipment (such as motors, servos, receivers, and speed controllers) that gets recycled and reused in new RPAS builds.  The assumption that all RPAS pilots replace their fleets once per year is not realistic.  This Remote ID mandate would create large financial burden on the average RPAS hobbyist.

Comment: 

The assumptions made in this section make sense for commerical operations that use RPAS as a tool. These operations are motivated to keep their RPAS up to date as newer systems will often have improved cameras, better endurance, enhanced features, and improved automation. 

Recreational operations, on the other hand, are generally not motivated to replace their fleets on a fixed schedule. As mentioned, I personally have model aircraft that I built in 2005 that I still fly regularly, and my newest aircraft are technologically very similar to the aircraft I learned to fly as a child. Recreational RPAS do not have a set "life-cycle" as is assumed here. 

Especially as model aircraft get smaller, the become less and less tolerant of added weight. These designs are generally highly optimized structurally and designed to fly best at a very specific wing loading. If I choose to make my smallest RPA compliant with this proposal, the addition of even a 10g Remote ID module will significantly affect the flying characteristics of the aircraft.  

Comment:

The Transport Canada approach to oversight of Safety Assurance Declarations, is risk-based, and TC does not automatically review every Safety Assurance Declaration it receives. When it does perform oversight of these declarations, thus far this oversight has been limited to a review of a declarants test plans, reports, and other substantiations. Oversight has not extended to independent verification of fielded system performance. 

The intent stated in this NPA is that aviation inspectors and other law enforcement personnel could issue AMPs to RPAS operators found to be non-compliant with the Remote ID rule. If a Remote ID broadcast module is sold to the public, and it turns out that the module is not compliant for a technical reason (for instance the enforcement partner's mobile device can't read the particular remote ID signal transmitted by the RPA), can an AMP be administered? The RPAS operator has fulfilled all of their regulatory responsibilities by equipping with a module listed on the TC list of declared equipment.  In this case it was the police officer at fault as they did not have a Remote ID receiver that was compatible with the particular equipment being used.

Comment:

I have concerns over how the Remote ID information gets linked to personal pilot accounts in the Drone Management Portal (DMP). 

I seems that the assumption is that most drone manufacturers would use the serial number of the RPA as the unique RPA identifier for RID purposes. This means that when the RPAS is registered in the DMP, the Remote ID unique identifier would be the RPAS serial number and this serial number would be used to link Remote ID reports to a personal account in the DMP. 

It is less clear how this would work with Broadcast Remote ID modules that are added on to existing RPAS that don't natively support Remote ID. If the intent is to follow the FAA module, RPAS pilots would need to register their Broadcast Remote ID modules with the DMP (almost as if they were a stand alone RPAS). Presumably the RPAS pilot would then be free to move this module around to any aircraft in their fleet that doesn't support Remote ID. If this is the intent, clarification is needed as to whether each aircraft within the fleet also needs to be registered. Is the expectation that a RPAS pilot who has already paid $10 to register their aircraft needs to pay another $10 to register their Broadcast Remote ID module? On the flip side, if an RPAS pilot has already registererd their Broadcast Remote ID module, are they required to pay an additional $10 for every individual RPA that they attach the module to? It would seem that, in this case, the Broadcast module is performing the role of connecting the RPAS with the registered owner in the DMP, therefore it seems that registering every aircraft in the fleet has very little added benefit (other than a noticeable financial burden on recreational operators who often have large fleets of model aircraft). 

Will I be protecte if someone (intentionally or unintentionally) programs their remote ID module with the information that is linked to my account and then uses that drone for a criminal operation? It is very easy to build Remote ID transmitters and program them with any unique identifier. Under this scenario, my decision to comply with the Remote ID regulations exposes me to the possibility of investigation if a drone ID tied to my account is detected doing an operation that violates CAR Part IX. Even if this is a highly unlikely situation, it would make many RPAS operators hesitate about submitting their Remote ID information to the Drone Management Portal.  

Comment:

As discussed, the assumption that RPAS have life-cycles is very commercial-drone-centric, and does not reflect the reality of recreational RPAS operations.

As a member of the model aircraft community, I don't expect to EVER purchase an RPAS that is Remote ID compliant "out-of-the-box". Therefore none of the cost mitigating measures described here apply to me.

This information is only available to RPAS pilots that fly while also monitoring Remote ID signals. As a VLOS pilot, I am maintaining visual contact with my RPA during flight and therefore I generally am not monitoring other screens for Remote ID transmissions. This is not a legitimate benefit to the RPAS PIC.

For a law abiding RPAS pilot operating VLOS, public acceptance does not come from people being able to use their phone to identify me on a map. 

Responsible VLOS RPAS operations are done such that the RPAS pilot is always obvious to those people who can see the RPA. Public acceptance for RPAS operations come from the operator being available to answer questions and demonstrate my RPAS capabilities, NOT from publicly broadcasting my personal data.

Comment:

I disagree with the statement that because data is not personally identifiable to me that it doesn't have the ability affect my privacy, or harm me in other ways. If someone specifically wants to target me personally as a compliant drone operator, they only have to receive and record the data transmitted by my Remote ID module, and report that information as operating in a negligent or hazardous way. As has been already discussed above, someone could program that data onto their own drone (or Remote ID spoofing module) and then use that Remote ID information in reportable incidents.

Furthermore, once someone links the public identifiers to me (by watching me fly at a park for instance) they can use this information to personally identify me moving forward. 

Issues such as these will tend to discourage people who are concened with data privacy from registering their Remote ID information on the Drone Management Portal. 

Comment:

As someone who builds their own RPAS, I have specific standards of practice to ensure that my radio link is reliable, and operates to the maximum range possible. The primary means of controlling EMI on my aircraft is to limit the number of transmitters on the aircraft to only those required for flight, and to ensure that if RPA to GCS telemetry is required, that the downlink occurs on a different frequency band from the uplink data.  

By requiring the addition of a third party Broadcast Remote ID transmitter you are adding an unnecesary downlink to an RPA that is often highly space constrained (the antennas can't be phyisically separated from each other), as well as power and weight constrained. For the most simple types of model aircraft, I do not have reliable way of determining if the Remote ID broadcast module is negatively affecting my primary C2 link.

Comment:

Since CAR Part IX came into force the model aircraft community has found time and time again that any added regulation impedes the growth of the RPAS industry at a recreational level. I don't expect that remote ID will be any different. With CAR Part IX there was a large group of non-MAAC recreational flyers who left the hobby because of the (rightly or wrongly perceived) complicated regulations that needed to be followed. With the loss of the MAAC exception there was another loss of participants to the hobby and many club fields closed. 

While commercial drone operators will find ways to comply with the Remote ID regulations out of necessity, there will be mayn recreational drone pilots who find that Remote ID is the "last straw" and decide that the added technilogical and financial burdens combined with the loss of privacy and the threat of enforcement and fines makes the hobby no longer enjoyable. With the loss of recreational operators, there will be a decline in companies making model aircraft kits. Mandating Remote ID on Basic VLOS operations will be another blow to the hobby. 

Comment:

This section is omitting the cost of oversight for Remote ID declarations. As discussed above, if non-compliant Remote ID modules are accepted onto the declaration list there is a large probability of AMPs being issued to RPAS pilots who are completely compliant regarding their responsibilities under the regs. As discussed above added regulations will certainly impede the growth of the RPAS market especially at the recreational level.

ISED will also have added costs as Broadcast ID modules will need to be tested for compliance at an ISED-recognized testing facility and then submitted for Certification Body Review. 

It is not quite clear what is meant by "increased pilot awareness" that will benefit the government of Canada. It should be noted that in a vast majority of Basic and Advanced VLOS operations, there will be no one receiving the Broadcast Remote ID signal. So if the intent is that more people will be aware of the operation, that will not be the case. If the intent is that other pilots will be more aware of other RPAS operating in their vicinity, while this may be the case for some advanced RPAS that are equiped with a map-display and "remote-ID-in", however, the vast majority of RPAS operators (especially recreational VLOS operators) will be too busy safely operating their RPAS to monitor yet another display. In addition it has also been acknowledged in the NPA that Broadcast Remote ID signals are very short range. RPAS pilots will only be aware of other RPA via Broadcast Remote ID when those RPA are closer than a few hundred metres from the Remote ID receiver.

Add notes on compliance and enforcement problems.

Comment:

As discussed above, Remote ID will only assist in identifying the "Careless" and the "Clueless" operators while doing nothing to identify most "Criminal" operations. 

As a responsible RPAS pilot I would like anyone that has questions or issues with how I am operating my RPAS to come up to me and ask me in person, at the time that I am performing the operation. I have educated countless individuals on model aircraft while operating at local parks and empty sports fields. I have always found people to be curious and interested. Generally, in these cases I'm able to answer their questions, and if there are any specific concerns I can address them and improve social acceptance of drones directly at the grass-roots level. 

As someone who abides by the Part IX regulations, I am always easily identifiable as the pilot of the RPA in question. There is never any doubt that "the person holding a controller and starting at that aircraft" is the one performing the operation.  From my perspective, giving people a way to report me directly to government agencies is exactly the opposite of "promoting social acceptance" of drones, and is a huge step backward for the growth of the hobby.

Comment:

Refer to my list of problematic regulations

Comment: 

Please clarify. This seems to imply that the  CBO would be responsible for registering member RPA with Transport Canada?

Keeping an up to date member list is no problem, but it would be impossible to keep an up to date list of member aircraft registered. The nature of model aircraft is a hobby is that a members fleet is in a continuous state of flux. Crashes, repairs, new builds, purchases sales, means that managing an up to date list of every aircraft in every member's fleet would be impossible.

Comment:

It's not clear what is meant by programming. If it is a training curriculum that is fine.

I think we should debate the need for the CBO to declare fixed sites to TC, or if the CBO should simply have a list of fixed sites available for TC review upon request. 

Is it TCs intent that the list of fixed sites be added to the DSST for public guidance? Will it be shared with commercial operators to warn them to expect heavy RPA operations without Remote ID?

Comment:

MAAC needs to be careful about how this is implemented. If the CARS are written such that non compliance automatically results in revocation of CBO status, then we are no better off than the Exemption we had before (one tine rule broken and the whole thing comes crashing down). 

There needs to be some discretion on the part of TC written into the regulation so that a judgment call can be made about whether a particular situation can be resolved without revoking the CBO status.

Comment:

MAAC should ask for clarification here regarding whether TC is approving safety procedures, or simply accepting them. As the subject matter expert on safe model aircraft operation, I would be concerned if the MAAC safety code could be at the whim of the Transport Canada inspector who is assigned to the file. If MAAC "renews" it's CBO status because of an editorial change to the safety code, or because of a change in leadership, there is a risk that if a more cautious inspector is assigned to the file, they might reject the application based on something in the safety code that has an established track record.

Comment:

This duty to consult requirement needs to be written carefully such that if the party to be consulted does not respond, MAAC is protected and can still establish the fixed site. For example, MAAC found it very difficult to consult with NAV Canada and was not able to establish an airspace agreement (which partly led to the loss of the exemption). We all also know about fields that have neighbors who are less than enthusiastic about the model aircraft activity, and may refuse consultation as a way to unilaterally stop the location of a fixed site. 

MAAC should request that the duty to consult be something that can be satisfied by a MAAC consultation process that seeks input, but that doesn't completely fall apart if the consulted parties are non responsive.

Comment:

Currently all MAAC members have a unique member number that is issued to them when they first join the organization. This number is theirs for life, and the MAAC safety code requires that all members put this number somewhere on their model. There is no unique number generated per airframe because as discussed above, MAAC member fleets can be very fluid with significant annual turnover through crash-damage, repairs, trades, sales and new acquisitions. The MAAC number written in or on the model serves to tie the model to the MAAC member who has care and control over that aircraft.

In addition to this, MAAC member fleets are not like commerical drone fleets in that MAAC members will only ever operate one aircraft at a time (in contrast to a commercial drone operator which might often send different operators with different airframes to different jobs). Because each model is unique and often has a lot of time and effort put into it by the owner, lending aircraft to other pilots to operate is done very rarely. 

Linking a particular airframe to a particular pilot should be all that is required to support the safety and security requirements of Transport Canada. If an airframe is found in an area that it should not be (i.e. crashed at an airport, or inside a secure/restricted area), the MAAC member number will link directly to the owner/operator of that aircraft, and there is no added value to having a unique number associated with the airframe. 

Theoretically, MAAC could issue a block of "tail numbers" to each member. So that member # 1234 might number their airframes as "MAAC-1234-1", "MAAC-1234-2", "MAAC-1234-3" and so on, however, as discussesd there is very little added value if an incident aircraft is the "-1" or the "-2" airframe owned by member "MAAC-1234". As mentioned above, simply adding "MAAC-1234" to the airframe uniquely identifies the individual operator who has care and control of that airframe. 

Given the fluid nature of MAAC member fleets, allowing airframes to simply be assigned the member number would also avoid a great deal of confusion when, for instance, an aircraft is repaired, or an engine or radio equipment is added. Many times in the hobby I have repaired a crash by building or purchasing a new wing. Would an airframe with a new wing require a new "tail-number" to be issued by MAAC? What about an engine replacement? What about if all parts except for the RC receiver is replaced? Would I have to inform MAAC if I sell an airframe to a friend? Would I have to inform MAAC if I don't fly an aircraft for a few seasons? Requiring a unique number for each airframe raises a large number of questions, adds a great deal of complexity, and adds an enourmous paperwork burden for MAAC and MAAC members for absolutely no safety or security benefit. 

There is also a key problem with the current registration requirements related to the model aircraft community that has been hinted at above. RPAS owners are allowed to replace any part of their RPAS and still use the same registration number. Effectively, a Part IX pilot is within their rights to register for a single RPAS number, and use the registration number on all of their aircraft. This strategy makes even more sense when one considers that members of the model aircraft community only ever fly one aircraft at a time. One would never seee more than one RPAS registered to Tom's Basement airborne at one time. When I land and decide to fly another airframe, through the act of linking my RC transmitter with the next airframe, from a practical perspective, I have simply replaced all parts of other RPA associated with a particular registration number.  

Evectively, the way that CAR Part IX is written today, members of the model aircraft community can have fleet registration if they so desire. I know that it would be appreciated by the model aircraft community if the CBO framework would support putting only the MAAC member number on each airframe without the need to differentiate between model aircraft somehow. 

Comment:

It should be noted that prior to CAR Part IX, MAAC fixed sites operated for decades within controlled airspace and even from aerodrome or airport properties without a recorded instance of a model aircraft interfering with "full-scale" air traffic. It is quite easy to operate an RPAS safely inside controlled airspace, and the model aircraft community has been doing this using the MAAC safety code for much longer than "drones" have existed. 

Model aircraft operators at fixed sites are acutely tuned to air traffic in their area. I have personally been at a MAAC club field when an unannounced medical helicopter landed at the flying site. All model aircraft landed when the medical helicopter circled for an inspection pass and gave way for the helicopter to land (it was dealing with a nearby traffic incident). Partly because of the lack of on-board stabilization, but primarily because model aircraft operations are conducted truly VLOS, conflict with full-scale aircraft is never an issue. 

In addition to this, not all ground-level controlled airspace is the same. While the Class C airspace near runway thresholds will obviously be very busy, traffic in most of a Class C control zone is kept several hundred feet above ground.

Comment:

As mentioned above, the fixed site information transmitted to TC should only include info shared on the DSST or with NAV Canada. Other policies and procedures should be kept and updated with MAAC as necessary and be available upon request. In the case of MAAC, MAAC has spent a lot of time and money developing safety regulations and operational frameworks. While some of these can be shared with Transport Canada, some of it may be considered MAAC proprietary and shared only with MAAC members. While safety is obviously something that should be shared and encourange with all, there are certain elements of MAAC procedures, or practices that will be reserved for MAAC members only. 

Comment:

Given the past history of the MAAC exemption,  a CBO framework needs to be carefully constructed to separate the responsibilities of the CBO from the responsibilities of the individual pilots who operate under the CBO umbrella. 

For a robust and resilient CBO framework to exist, revocation of the CBO status must be reserved for fundamental organizational breaches of the CBO contract, and not for infractions of individual members of the CBO. For instance, a CBO framework needs to ensure that if an individual is in violation of any CBO operational rules, that individual would no longer be operating "under the CBO", and would rather be subject to the rull requirements of the CAR Part IX rules.  We have to acknowledge that even model aircraft operators aren't perfect (gasp!), and sometimes they don't strictly follow every rule. CBOs must not be subject to dissolution every time one of their member operators violates one  of the CBO (or Part IX) rules. 

On the otherhand, it would be reasonable to revoke a CBO accreditiation in the event that the CBO rules are found to be inadequate (and there is a refusal to update them) or other systemic violations (such as non-responsiveness to TC communication or requests).

Comment:

When considering whether or not there a fee related to being a CBO is introduced, Transport Canada should consider the existing organizations that already govern other types of recreational aviation in Canada. The Soaring Association of Canada (SAC)  and the Hang Gliding and Paragliding Association of Canada (HPAC) are both the governing bodies for their sports in Canada. Both provide frameworks for licensing, instructional syllabi, and safety management systems to promote safe recreational aviation in Canada. Neither SAC nor HPAC pay a fee to Transport Canada to act in this capacity.  From the description in this NPA, the only difference between the CBO model described here and the existing role of SAC and HPAC in the Canadian aviation ecosystem is the fact that under this CBO ecosystem there may be alternate means of compliance to certain Canadian Aviation Regulations. 

Given that other community based organizations supporting safe integration of recreational aviation into the the Canadian Airspace do not pay fees, Transport Canada needs to ensure that any fee structure assessed upon a RPAS CBO is fair and equitable. 

If a "per flying field" fee structure is considered, it should be noted that MAAC model airplane fields can be much more fluid than traditional aerodromes and airports are. While some lucky clubs maintain a single flying site for years or even decades, many clubs are forced to move occasionally due to land access, suburban sprawl, and other reasons. Clubs will also often . Please consider the financial burden on a Community Based Organization  if a fee needs to be paid each time a new flying field is activated or deactivated.  If assessed on a "per site" basis, fees for CBOs will quickly add up and become an impossible burden for most CBO. 

Finally, consider that the goal of a Community Based Organization is to increase the safety of related operations, as well as to reduce the burden on TC of surveilling and monitoring a large subset of the RPAS operational population. In general, Transport Canadas goal should be to streamline the path to aviation safety rather than putting barriers in that path (such as fees to establish safety oriented CBOs).