Re: about draft-ietf-mobike-protocol-01.txt (issue 40)

 In your previous mail you wrote:

   Here are some comments and suggested
   changes, embedded in Pasi's comments.
   
   Here's a suggested edit:
   
      ... MOBIKE is making it possible for a remote access VPN user to move
      from one address to another while keeping the connection with the VPN
      gateway active.
   
   =>
   
      ... MOBIKE is making it possible for a remote access VPN user
      to maintain a single VPN connection with a gateway, despite
      moving from one address to another or having multiple addresses.
   
   Similar change in Section 1.1. Is there anything else Francis?
   
=> are you joking? Either we really take multihoming into account
or we don't claim we deal with more than mobility.

   The charter indeed limits us to "failover" semantics
   of multihoming.

=> you already know that I don't argue for load balancing but
for support of what I call the SCTP model of multihoming.

   But perhaps this is about IPsec SA movement granularity?

=> yes

   But we already discussed that earlier and arrived at a conclusion.

=> this is this conclusion I contest. BTW the charter explicitely
mentions SCTP so either we fix the charter or we follow it or we
make clear the document describes a partial solution and the work
about the full solution will be done later (i.e., a change in the
milestones).
   
   I tend to agree that its better to have a single mechanism
   that simply replaces the set, rather than a "diff" scheme.
   The latter would work better when there's a very large
   set of addresses, but I think simplicity is more valuable
   than covering that case.

=> this is a matter of taste. I am not convinced that sending the
whole set at any change is really simpler than sending diffs but
both give the same capability...

   In any case, we know that there are other limitations in our
   technology for dealing with large address sets, e.g, ability to
   probe for a working address pair.
   
=> this is just a side-effect of the "IKE will do everything by itself"
direction which of course can't deal with large address sets.

   I'm not sure I understand how Section 2.2 specifically
   helps this,

=> Section 2.2 is about the management of a peer address set and
the transport document relies only on this mechanism.

   so get your transport mode document polished so that we'll have
   something to discuss there!
   
=> IMHO the wording can be better (help me!), the references
shall be fixed as soon as the protocol is published, I can't see
something else.

   Hm. I'm not sure I understand this. I thought SPD
   deals with the unprotected packets, rather than the
   outer addresses, which I think we are working with.

=> the SPD-S entries have two main parts:
 - conditions: traffic selectors which are translated into TS payloads
 - an action, i.e., parameters for the protection with the IPsec
   protocol to use, ..., and the tunnel endpoint addresses.
In the ASN.1 syntax we get:
SPDEntry->IPsecEntry->processing->TunnelOptions->TunnelAddresses

   I would understand the SPD entry update if we
   were talking about transport mode, however.
   
=> no, this is explicitely about the tunnel mode and we speak about
SPD entries only because this is the place the tunnel endpoint
addresses are in the 2401bis formal description (this is why
we also speak about better implementation dependent hints).

   >>- in 2.3 it should be clearer that NAT_XXX notifications are
   >>mandatory.

=> I should have written recommended, i.e., a SHOULD but not a MUST.

   Yes. Btw, we do intend to be fairly strict about
   re-opening issues. (We will re-open an issue only if
   we detect a new and/or serious technical problem.)
   
=> I'll ask the IESG what to do when a WG ignores its IETF charter.
My concern here is we can't work about SCTP/multihoming support
in IKEv2 (RFC 3554 for IKEv2 for instance) because it is in the
MOBIKE charter.

Regards

[email protected]