GIST peering concern

While implementing our own NSLPs and the API between GIST and NSLPs, we 
came across something in the current NTLP i-d we think might be a 
problem.

In section 4.3.2 "Local Processing and Validation" it is stated that: 
"The first option (peering) MUST be chosen if the node is the final 
destination of the Query message, or if the GIST hop count has reached 
zero." We think this is problematic for at least two reasons.

1) This removes flexibility from the NSLP application and forces certain 
   behaviour. Thus it complicates NSLP application logic, since the NSLP 
   must be aware of this exception to its peering "wishes".

2) It could be possible to overload resources, such as memory and UDP 
   send rate, of a GIST node. Sending Queries with an (intentionally)  
   low GIST hop-count would lead to nodes being forced to peer, though 
   it is stated in the same section (4.3.2), that a node can decline 
   peering for "overload protection reasons".

We suggest that an error message be defined for the case when a flow 
endpoint does not wish to peer, or that the definition of the "Endpoint 
Found" message be extended to include this case. Currently section 4.3.4 
seems to state, that "Endpoint Found" can only be sent when the NSLP is 
not present on the GIST node.

 Regards,
 Nuutti, Teemu and Lauri

-- 
Lauri Liuhto