Comments on PRR in draft-ietf-midcom-semantics-06.txt

These comments come about because of my increased understanding of NATs 
as a result of study of the NAT MIB.

1. According to the NAT MIB, the NAT type is a configured property of 
the interface and therefore cannot be arbitrarily chosen.  It is for 
this reason that I think the service type parameter should not be 
present in the PRR.

2. The internal interface parameter should only be needed if the MIDCOM 
agent is acting on behalf of an internal endpoint which is served by a 
different interface.  Otherwise I would expect that the middlebox would 
use the internal interface on which the PRR arrived.  Text should be 
added to indicate this default behaviour.

I have no idea how the MIDCOM agent would know the applicable interface 
identifier and whether it has to use it.  It seems to me there is a good 
argument for expecting that the MIDCOM agent and the internal endpoint 
are served by the same internal interface, simply because the MIDCOM 
agent is, by assumption, on the signalling path for the application.

3. I don't see the value of having the external interface parameter. 
Either the internal address-port A0 is already covered by a binding or 
it is not.  If it is, the external address is determined by the existing 
bind.  If it is not, it should be up to the middlebox to choose the 
external interface, based on existing mapping table entries, load 
balancing considerations, etc.

4. The possibility that A0 is a range of addresses rather than a single 
address is problematic.  The problem comes about if different addresses 
within the range are covered by different existing bindings or map 
entries pointing to different external addresses.  I suppose it will be 
necessary to have a return code indicating that assignment could not be 
made due to conflict.  Alternatively we can disallow wildcarding of A0 
-- something that would make sense to me in terms of application 
requirements.

5. We have to accept the possibility that a PER following a PRR may 
fail.  This may be because the middlebox has selected an external 
interface at the PRR stage through which the external endpoint address 
A3 turns out to be unreachable.  The second possibility is in the 
twice-NAT case and has been discussed already: A3 may turn out to be 
contained in a binding that conflicts with the mapping to internal 
address A1 provided as a result of the PRR.  Text should be added to the 
PRR description to indicate this.