Re: Issue 24: NAT prevention details (was: Review of draft-ietf-mobike-protocol-00)

+++++++++
Or NO_NAT_POLICY and NAT_POLICY_ERROR?

Best regarts,
Pasi
++++++++++

The above suggestions sound more intuitive.  The sender is trying to establish/enforce its local policy of NO_NATs in the way and the receiver helps by saying I detected none, or there was a NAT and therefore your policy cannot be supported.

We might wait a little to see if others might have suggestions too (Andreas had some thoughts).

thanks,
Lakshminath





[email protected] wrote:

>Lakshminath Dondeti wrote:
>  
>
>><LD> The labels NAT_PREVENTION, NAT_PREVENTED are confusing.
>>For a little while I thought they are the same, but realize
>>they are different.  NAT_PREVENTION seem to mean that the
>>sender is guaranteeing/indicating that there is no NAT.
>>Perhaps, NAT_NOTSUPPORTED or NAT_ABSENT or something like that
>>might be more appropriate.  Instead of NAT_PREVENTED,
>>NAT_PRESENT or NAT_DETECTED might be more appropriate.  The
>>Initiator then can compare its claim from its state that
>>NAT_ABSENT against NAT_PRESENT to detect that its claim is
>>incorrect.  </LD>
>>    
>>
>
>Hmm... here the sender of the NAT_PREVENTION payload (initiator)
>is informing the responder that its policy is not to use paths
>that contain NATs. If the responder notices that a NAT is
>present anyway, the request fails with error code NAT_PREVENTED.
>
>But maybe we could figure out better names for these payloads.
>How about "NAT_PREVENTION_FAILURE" instead of "NAT_PREVENTED"?
>It would perhaps tell more clearly that it's an error
>indiciation?
>
>Or NO_NAT_POLICY and NAT_POLICY_ERROR?
>
>Best regarts,
>Pasi
>
>  
>