Re: 54 - marcelo's editorial comments

Pasi,

>>>9. In section 4.4 i think that the Dead Path Detection 
>>>indication should be mentioned as one of the events that should 
>>>lead to an address change (perhaps a reference to section 4.9 
>>>would be useful too) along with
>>>      
>>>
>>Suggested change:
>>
>>   o  An IKEv2 request has been re-transmitted several times, but no
>>      valid reply has been received.  This suggests the 
>>      current path is no longer working.
>>
>>=>
>>
>>   o  An IKEv2 request has been re-transmitted several times, but no
>>      valid reply has been received.  This suggests the 
>>      current path is no longer working. See also Section 3.9.
>>    
>>
>
>Section 3.9 is about NAT prohibition, and doesn't need to be
>referenced here?? In -04, Section 4.9 was about path testing, but
>that's not really very closely related either. IMHO Marcelo's
>original comment is already handled here: failing DPD == "IKEv2 
>request has been re-transmitted several times, but no valid reply 
>has been received".
>
>My proposal: no text change.
>  
>
Ok.

>>>10. In section 4.4, it is stated that:
>>>
>>>  o  It updates the IPsec SAs associated with this IKE_SA 
>>>     with the new addresses (unless this was already done 
>>>     before sending the request).
>>>
>>>As i understand it, the reason for updating the addresses here 
>>>is because the reply plays the role of a return routability 
>>>check, right? It would make sense to state so, for instance 
>>>adding something like
>>>
>>> o  It updates the IPsec SAs associated with this IKE_SA 
>>>    with the new addresses (unless this was already done 
>>>    before sending the request i.e. no return routability 
>>>    check was required, see 4.6).
>>>      
>>>
>>Ok. The current Section that this text is in is by the way 3.5.
>>    
>>
>
>The pointer to 4.6/3.5 is IMHO confusing; the real pointer is to 
>the step "Updates the IPsec SAs..." step earlier in this section.
>  
>
Yes.

>How about this?
>
>   o  It updates the IPsec SAs associated with this IKE_SA with
>      the new addresses (unless this was already done earlier
>      before sending the request; this is the case when no
>      return routability check was required).
>  
>
Ok.

>  
>
>>>I am not sure that the example of the certificate is a good 
>>>example... what if the certificate is self signed? (i don't know 
>>>if those are supported) but in any case, i don't know how simple 
>>>is that certificates can prove address ownership (this depends 
>>>of the checks performed by the CA about address ownership)
>>>      
>>>
>>Right. Suggested text change: s/the address is included in the
>>peer's certificate/the address is included in a certificate given
>>to the peer by a trusted authority/
>>    
>>
>
>My proposal: 
>
>  [..], or the address can be verified by some other means 
>  (e.g., a certificate issued by an authority trusted for 
>  this purpose), [...]
>  
>
Ok. I think that also addressed Tero's concern with
my original text proposal.

--Jari