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

Francis Dupont wrote:

>=> are you joking? Either we really take multihoming into account
>or we don't claim we deal with more than mobility.
>  
>
Francis, it seems that we have multiple definitions
of multihoming. Or multiple levels of support we could
provide. I think it would be more productive to argue
what type of multihoming to support, than to argue
that we do or don't support multihoming.

I suspect that the group's desire to do any specific
type of multihoming relates very much to the expected
usage.

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

>   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. 
>
Yes. But I'm sure you also understand that we
can't keep on arguing over an issue for ever, we
need to make decisions at certain points in time,
even if sometimes there are people who disagree
with those decisions.

>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 think we have a pending milestone change coming in any
case. E.g., what's the timeplan and interest for reduced
tunnel overhead and pfkey work? Should the transport doc
be in the milestones?

I see the SCTP support as one of the use cases in the
charter, along with the main use case of roaming VPN
users. My understanding has been that we are not
required to cover everything that we need to do in
one document. Indeed the transport document has
already been discussed as an extension over base
MOBIKE.

>   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.
>  
>
Ok. I'll take a look.

>   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).
>  
>
Ok. Thanks for the clarification.

>=> 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.
>  
>
The charter allows and requires us to work on SCTP
support. But it does not promise that our first document
delivers this support. In fact, the charter makes it quite
clear what the main scenario is.

This should not prevent later support for SCTP,
Mobile IP and other specific applications, however.

--Jari