@johan thanks for the reply.
Can I drill down on one particular issue...
I'm sure you are aware that one of the fundamental design principles of the Internet, and perhaps one of the reasons it has been so successful, is that the network is dumb and the intelligence is at the edge (see http://www.isen.com/stupid.html)
My goal here is to see how the LoRaWAN spec (and TTN implementation) can be interpreted (implemented) in a way that preserves the "stupid network" principle.
In reading the LoRaWAN spec it seems you can assume that when they refer to a Network Server they mean the device in the cloud that the nodes are talking to, which perhaps also hosts the application. This is perfectly compatible with the requirement for performing re-transmissions (§ 4.3.1.3) and frame counting (§ 4.3.1.5)
Curiously, Section 5 continues to use the phrase "Network Server" but it seems they are here referring to their "Gateways". They emphasise that MAC messages aren't relayed to the applications host and they are explicitly described as messages between the Node and the Gateway. It would seem they have changed the terminology in this section so when they say "Network Server" they mean "Gateway".
For TTN, I would interpret Section 5 as defining communication of MAC messages between Nodes and Routers since TTN Gateways are little more than L2 repeaters.
Section 6 introduces another couple of curve balls...
AppSKeys are pretty straightforward, they are the means of securing communication between Nodes and Applications and the spec says the Network Server has visibility of these keys; more evidence that the Network Server is (rightly) the host that the application runs on (or at least close to it, like a load balancer or WAF in traditional networks.)
NwkSKey is more difficult to interpret. It ensures the integrity of message MICs and for encrypting MAC messages. It would seem that despite the spec stating this is a function of the (same) Network Server it is actually only the Gateway (TTN Router) that needs to handle the NwkSKey. Clearly this is the case for MAC messages. For MICs, I would argue that once the packet has arrived at the TTN Router and its MIC integrity is validated, it can be forwarded to the Handler using a secure and reliable transport (TCP with appropriate encryption) and the mechanism of NwkSKey is no longer relevant.
Finally (?) we have OTA. This is (in principle) a lot like DHCP and DDNS and I see no reason why it needs more intelligence in the network than that of the smart TTN Router with registry service provided in the TTN Broker.
The remainder of the spec refers to the role of "Network Server" with regard to Class B end-devices so I won't go on. I think I've made my point - I don't think there is a need for an entity called a "Network Controller", it's just a name LoRaWAN use to refer interchangeably to the host running the application and, sometimes, the "gateway".
Aled