--------------------

Pekka Savola (2005-09-19):

editorial
---------

   The initiator uses the set of responder addresses as an input to its
   address selection policy; it may at some later point decide to move
   the IPsec traffic to one of these addresses using the procedure
   described in Section 2.3.  The responder normally does not use the
   set of initiator addresses for anything: the addresses are used only
   when the responder's own addresses change.

==> the last sentence needs a forward reference (Section 2.3.4 in my
proposal).

Such information itself MUST NOT be used to conclude than
   an update is needed: instead, the initiator SHOULD trigger dead peer
   detection.

==> I suggest adding explicit ref to DPD, especially when written in
all-lowercase.

   The description in the rest of this section assumes that the
   initiator has already decided what the new addresses should be.  When
   this decision has been made, the initiator

   o  Updates the IKE_SA and the IPsec SAs associated with this IKE_SA
      with the new addresses, and sets the "pending_update" flag in the
      IKE_SA.

==> s/initiator/initiator:/ (and similar elsewhere)
==> personally, I might have just repeated the "initiator" in each bullet,
but this is correct as well.

  o  When the window size allows, sends an INFORMATIONAL request
      containing the UPDATE_SA_ADDRESSES notification payload (which
      does not contain any data), and clears the "pending_update" flag.

      Initiator                  Responder
     -----------                -----------
      HDR, SK { N(UPDATE_SA_ADDRESSES),
                [N(NAT_DETECTION_*_IP)],
                [N(NO_NATS_ALLOWED)],
                [N(COOKIE2)] } -->

==> s/flag/flag, for example as follows:/ (or something like..)

                            <--  HDR, SK { [N(NAT_DETECTION_*_IP)],
                                           [N(COOKIE2)],  }
==> s/COOKIE2)],/COOKIE2)]/

  MOBIKE payload relating to updating addresses are encrypted,
   integrity protected, and replay protected using the IKE_SA.

==> s/are/is/ or s/payload/payloads/

   However, security associations originally created for the protection
   of a specific flow between specific addresses may be moved through
   MOBIKE.

==> "moved" seems a bit odd choice for a word here?

   to use MOBIKE are configured in a manner that takes into account that
   a single security association can be used through different paths at
   different times.

==> maybe s/paths/paths of varying security properties/ to spell it out
loud again

   reply is received, MOBIKE will usually consider the path working;if

==> s/;/; /

--------------------