Re: Issue 62: Editorial comments from Francis (was: review of draft-ietf-mobike-protocol-04.txt)

 In your previous mail you wrote:

   > => as this has some limitations IMHO there should be a pointer to
   > the section 3.4 "Limitations".
   
   Earlier I've received comments that the document has too many pointers
   back and forth, so I've tried to avoid them (unless the paragraph will
   be difficult to understand with them).
   
=> this is a matter of taste: with pointers you have to turn pages when
you read the document, without pointers you have to read it twice to
catch the whole thing... I don't know what is the best for everybody,
for me it is the first (pointers).

   > => I believe the illustration needs the IP addresses and ports from
   > IP and UDP headers. If someone finds a good way to add them, the 
   > whole stuff will become far more readable.
   
   Yes, that's a good suggestion. How about something like this:
   
      1) (IP_I1:500 -> IP_R1:500) 
         HDR, SAi1, KEi, Ni,
              N(NAT_DETECTION_*_IP)  -->
   
                               <--  (IP_R1:500 -> IP_I1:500)
                                    HDR, SAr1, KEr, Nr,
                                         N(NAT_DETECTION_*_IP)
      <snip>
   
      3) (IP_I2:500 -> IP_R1:500)
         HDR, SK { N(UPDATE_SA_ADDRESSES),
                   N(NAT_DETECTION_*_IP) }  -->
   
   That is, use IP_I1,IP_I2,,.. for initiator addresses and IP_R1,IP_R2,...
   for responder addresses...?
   
=> this seems fine, thanks!

   > - in 4.3 page 10
   > 
   >    Note that if some of the initiator's interfaces are behind a
   >    NAT (from the responder's point of view), the addresses
   >    received by the responder will be incorrect.  This means the
   >    procedure for changing responder addresses described in
   >    Section 4.5 does not fully work when the initiator is behind a
   >    NAT.  For the same reason, the peers also SHOULD NOT use this
   >    information for any other purposes than what is explicitly
   >    described in this document.
   > 
   > => I have a problem with "this document". I propose to relax it in
   > "MOBIKE documents".
   
   How about rephrasing that to "...for any other purpose than what is
   explicitly described either in this document or a future specification
   updating it" ?
   
=> in the documents I thought about the "transport mode" one which uses
the additional addresses but can't be qualified as "updating".
I believe my proposal is better (and simpler/shorter).

   Hmm, yes, the paragraph needs some clarification. In some sense, 
   most of the information available to the host is to some degree 
   unreliable, and there's no way to avoid using some of that.
   
   How about rewriting the last sentence as follows?
   
      "Unreliable information SHOULD be treated only as a hint that there
      might be a problem, and the initiator SHOULD trigger dead peer
      detection (that is, send an INFORMATIONAL request) to determine if
      the current path is still usable."
   
   <snip>
   
=> fine.

   > - in 4.9 page 17
   
   >   IKEv2 Dead Peer Detection allows the peers to detect if the
   >   currently used path has stopped working.  However, if either of
   >   the peers has several addresses, Dead Peer Detection alone does
   >   not tell which of the other paths might work.
   >
   > => this text is fine but perhaps a bit late in the document
   > (i.e., path testing should be in the overview too)?
   
   Since this is not really new to MOBIKE, but just explains that
   the existing Informational exchange works, I'm not sure
   if adding more forward pointers would make any difference
   to the reader?
   
=> it was just a suggession.

   > => IPv6 environments are other obvious candidates for
   > NO_NATS_ALLOWED!
   
   Yes, Tero also pointed this out (see issue 59 for my proposal
   for text).
   
=> I'll try to reread all the other comments in time.

Thanks

[email protected]