66 - imprecise explanation of what nat cases are not supported

>
>
>>   "Does not fully support" means that no special effort is made to
>>   support this functionality.  However, if the alternative is losing
>>   connectivity completely, the responder can still attempt to proceed
>>   with the change, and depending on, e.g., the exact type of NAT, it
>>   may succeed.  However, analyzing the exact circumstances when this
>>   will or will not work is not done in this document.
>>  
>>
>I'm OK with the text being vague about the type of
>scenarios supported beyond the basic client-inside-NAT
>case. However, the above text appears to say that the
>responder is capable of detecting such situations,
>which I don't think is at least always true.
>

Here's some proposed text:

   "Does not fully support" means that no special effort is made to
   support this functionality.  However, if the alternative is losing
   connectivity completely, the responder can still attempt to proceed
   with the change, and depending on, e.g., the exact type of NAT, it
   may succeed.  However, analyzing the exact circumstances when this
   will or will not work is not done in this document.

=>

   "Does not fully support" means that no special effort is made to
   support this functionality.  Responders may also be unaware of
   NATs or specific types of NATs they are behind. However, when
   a change has occurred that will cause a loss of connectivity,
   MOBIKE responders will still attempt to inform the initiator of the
   change. Depending on, e.g., the exact type of NAT, it may or may
   not succeed.  However, analyzing the exact circumstances when
   this will or will not work is not done in this document.