Which, on VATSIM, there are rarely loas or procedures allowing turns and changes inside of a artcc/ccf airspace. So turns and the like, in theory, couldn't be applied on the VATSIM environment once a handoff has been initiated because there are no loas allowing it. The .65 doesn't define flight path as a nas route, etc. so to me that means it's heading, assigned or otherwise as that is how it's used elsewhere in the .65 in rules like passing and diverging, etc.
Yeah, but doesn't the overriding principle of General Control apply? Namely, the plane is your control while under your area of jurisdiction and that the handoff is nothing more than the transfer of radar ID?
No because the responsibilities of the transferring controller (5-4-5) now applies.
I want to throw in my two cents. My background is 8 years in the FAA, 7 of them being at two different terminal radar facilities. One has probably the most complex LOAs in the world between the TRACON and overlying center, and the other has probably one of the simplest (two different overlying ARTCCs).
5-4-5 b. simply means that once an aircraft is in automated handoff status, changes to the aircraft's flight plan information can't be made without verbal coordination. Consequently, they have made it impossible to do this by not allowing FDIO changes once an aircraft is in handoff status (speaking TRACON/TRACON and TRACON/ARTCC...I don't know what capabilities exist in the enroute world). Before ERAM, we had a requirement (in an LOA) to verbally coordinate all FDIO changes made within 15 minutes on initiating the handoff to ensure the receiving controller had the most up-to-date information.
The intent of that paragraph is not to forbid the initiating controller from working the aircraft in his airspace after an automated hand-off has been initiated. In fact, in many places, it would be impossibly to comply with that interpretation because aircraft go into automated handoff status without input from the controller.
LOA's don't have anything to do with how a controller may work an aircraft up to the transfer of control point. A lack of an LOA doesn't have anything to do with how a controller may work an aircraft up to the transfer of control point; they're totally unrelated.
Why then does 5-4-5 b. say
"unless otherwise specified by a LOA or a facility directive."?
Because some LOA's/Facility Directives require aircraft to be delivered at specific speeds/headings/altitudes, etc... regardless of requested speed/altitude/routing and FDIO changes after the handoff has been initiated would not change how the receiving controller would receive the aircraft. Some facilities have the ability to change data block information on other controller's aircraft (requested altitudes, assigned speeds, route information, etc....).
Another way to look at it is from the point of view of the receiving controller. If I take a handoff on an aircraft, where I don't have any LOA with the initiating controller's facility on how this aircraft shall be delivered, I expect that the aircraft will be at its requested altitude and on the route in the FDIO. If, 10 miles from the boundary, the aircraft turns 40 degrees for some reason, what do I care? As long as he's pointed back toward his routing before he is shipped to me, it doesn't affect me in the least. When I'm working ORD arrivals, I don't care if ZAU has airliners zig-zagging all over their sector before coming to me. The fact that there's an LOA specifying how those planes will be delivered eventually doesn't make a difference to me; once the aircraft is switched to me and enters my airspace, then I can worry about it.
Now, if somebody has decided that their interpretation is that once the handoff has been initiated, they can no longer give any control instructions without verbal coordination, that doesn't really affect me either, so have at it. That's clearly not the intent, but it doesn't affect my operation, and I wouldn't even know that was the case because I'm not listening to how the initiating controller is working his airplanes.
One last thought. There are facility managers and district managers and OMs and supervisors who have ridiculous interpretations on different things in the 7110.65 that are not FAA-wide. It could very well be a directive in Fairbanks that once a handoff has been initiated, you aren't allowed to give any other control instructions without verbal coordination. For a while at ARR ATCT, if the ATIS advertised runway 27, aircraft couldn't operate on runway 15, even if there were no other aircraft within 100 miles of the airport, because of the managers unfounded interpretation of a new opposite direction procedure. Meanwhile, the other 4 FAA towers in the area actually followed the intent of the directive and ran similar operations without an issue. Even ORD ATCT can't roll a 22L departure if a heavy lands on 28C because of wake turbulence because someone somewhere has interpreted the wake turbulence rules to mean that an aircraft just beginning its takeoff roll is considered to be flying through the heavy's flight path.
Particularly since it is VATSIM, it is not wrong for a controller to not give control instructions after initiating a handoff, but it's absolutely not wrong for a controller TO give control instructions after a handoff has been initiated.
I would love to see the "reject handoff" feature to be eliminated from VATSIM. That's one of the most unrealistic features on the ATC side of the network. If someone is flashing and I, for some reason, don't want to take the handoff (or the handoff should be going somewhere else -- it happens sometimes), then I'll ignore it or verbally coordinate, "hey, I think you meant to flash him at the low sector, not me." I take handoffs 20 miles outside of my airspace all day long (only because usually that's the edge of my scope). It wouldn't bother me to take one 100 miles away because I know the initiating controller is going to ship me a clean airplane.
