design draft issue: terminology alignment

>
>    Primary Path:
>
>       The sequence of routers traversed by an IP packet that carries the
>       default source and destination addresses is said to be the Primary
>       Path.  This definition is taken from [RFC2960] and adapted to the
>       MOBIKE context.


The protocol draft uses the term "current path" (and so does
the latest version of the SHIM6 draft where the primary path
term was originally taken from).

Use the term "current path" instead here in Section 2 as well
as in the rest of the document.

>    Preferred Address:
>
>       The IP address of a peer to which MOBIKE and IPsec traffic should
>       be sent by default.  A given peer has only one active preferred
>       address at a given point in time, except for the small time period
>       where it switches from an old to a new preferred address.  This
>       definition is taken from [I-D.ietf-hip-mm] and adapted to the
>       MOBIKE context.

The protocol draft does not use this term.

Peer address set is closer to what we want here?

(Also, I'm not sure the protocol we have actually communicates
the address preferences. The initiator makes a decision, but
does the ordering in an address update indicate preference?)

Also,

>    The MOBIKE protocol should be able to perform the following
>    operations:
>
>    o  Inform the other peer about the peer address set
>
>    o  Inform the other peer about the preferred address
>
>    o  Test connectivity along a path and thereby to detect an outage
>       situation
>
>    o  Change the preferred address

Again, not sure we actually communicate the preferred
information -- but I may be missing something.

>    Another MOBIKE usage scenario is depicted in Figure 2.  In this
>    scenario, the MOBIKE peers are equipped with multiple interfaces (and
>    multiple IP addresses).  Peer A has two interface cards with two IP
>    addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1
>    and IP_B2.  Each peer selects one of its IP addresses as the
>    preferred address which is used for subsequent communication.
>    Various reasons (e.g., hardware or network link failures), may
>    require a peer to switch from one interface to another.

Is this in line with what the protocol draft does?

>    Operational address pair:
>
>       A pair of operational addresses are said to be an operational
>       address pair, if and only if bidirectional connectivity can be
>       shown between the two addresses.  Note that sometimes it is
>       necessary to consider connectivity on a per-flow level between two
>       endpoints.  This differentiation might be necessary to address
>       certain Network Address Translation types or specific firewalls.
>       This definition is taken from [I-D.arkko-multi6dt-failure-
>       detection] and adapted for the MOBIKE context.  Although it is
>       possible to further differentiate unidirectional and bidirectional
>       operational address pairs, only bidirectional connectivity is
>       relevant to this document and unidirectional connectivity is out
>       of scope.

(snip)

>    Bidirectional Address Pair::
>
>       The address pair, where traffic can be sent to the both
>       directions, simply by reversing the IP addresses.  Note, that the
>       path of the packets going to each direction might be different.
>
>    Unidirectional Address Pair::
>
>       The address pair, where traffic can only be sent in one direction,
>       and reversing the IP addresses and sending reply back does not
>       work.

The explanation of directionality on the first definition
seems superfluous.

>    Figure 1 shows a break-before-make mobility scenario where a mobile
>    node changes its point of network attachment.  Prior to the change,
>    the mobile node had established an IPsec connection with a security
>    gateway which offered, for example, access to a corporate network.
>    The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took
>    place over the path labeled as 'old path'.  The involved packets
>    carried the MN's "old" IP address and were forwarded by the "old"
>    access router (OAR) to the security gateway (GW).

Consider talking only about routers, not access routers.

>    MOBIKE interacts with the IPsec engine using for
>    example the PF_KEY API [RFC2367].  Using this API, the MOBIKE daemon
>    can create entries in the Security Association (SAD) and Security
>    Policy Databases (SPD).  The IPsec engine may also interact with
>    IKEv2 and MOBIKE daemon using this API.

"IPsec engine" is a term that exists in RFC2401, I think. Use
"IPsec implementation" or some other term.

>    In order to address certain failure
>    cases, MOBIKE should perform connectivity tests between the peers
>    (potentially over a number of different paths).

I think they are called "path tests" in the protocol draft.

> Those external hole punching mechanisms are beyond the scope of

Firewall pinhole opening is a better term, I think.

>    One type of attack that needs to be taken care of in the MOBIKE
>    protocol is the 'flooding attack' type.  See [I-D.ietf-mip6-ro-sec]
>    and [Aur02] for more information about flooding attacks.

Called bombing attack earlier, and in the protocol draft.

--Jari