From Adrian Farrel:

> Section 6.1 and Section 8.4 
> A DoS attack can come from any node in the network. 
> Such a node can send a Q-mode Query message as though it 
> was forwarding it at the GIST level. The result, from any 
> GIST capable node that intercepts it, may be a D-mode 
> Response direct to the (spoofed) Query node. The Query 
> node will handle the Response (according to Rule 2) by 
> sending a "No Routing State" error message. 
> Please consider whether a Responder node should be 
> recommended to keep track of such events and rate limit 
> processing of new Query messages under such circumstances

> Section 6.2 
> Can I receive er_NoRSM in Awaiting Refresh state? 
> I think so because my sent Query refresh may have been 
> lost, the peer may have timed out the state, and I may 
> have sent Data. 

> Section 6.2 Rule 3 
> This action needs to check to see if Confirm was requested. 
> Should not send a Confirm if one was never requested. 
> 
> What if the er_NoRSM is sent in response to the Confirm? 
> This is opening a tight loop! (Such could arise if the 
> peer has 'lost' the Routing State. 

> Also, if you have sent several (say 100) Data messages 
> immediately after a lost Confirm, you will receive 100 
> er_NoRSM messages and (according to this state machine) you 
> will send 100 new Confirm messages. > 
> 
> This is not just a mater of implementation optimisation 
> because you are impacting the network and the adjacent 
> nodes. Further, this state machine is presented as 
> normative so variations from it will be tested by 
> certification labs.