Re: Issue list status & plea for help

Maureen,

Yes, I noticed this as well.

I'd suggest including it even earlier, in the abstract:

    ...MOBIKE allows hostst to update the (outer) IP addresses associated 
with IKEv2 and **tunnel mode** IPsec Security Associations...

            jak

----- Original Message ----- 
From: <[email protected]>
To: <[email protected]>
Sent: Monday, October 03, 2005 10:23 PM
Subject: Re: [Mobike] Issue list status & plea for help


> OK.
>
> The fact that we are only discussing tunnel mode is not explicitly
> mentioned until section 3.4 in this document.  There is one place in the
> introduction that mentions it, but only in passing.  Everywhere else, it
> is inferred and/or assumed.  Although it is said explicitly in section
> 3.4, but that is after we have read a lot of text without knowing this.
> Also, it is called limitations, rather than scope.  I suggest that you
> move this 3.4 to section 2. and call it scope.
>
> Here is suggested text:
>
> 2. Scope
>
> The scope of this document is limited to tunnel mode as the base version
> of the MOBIKE protocol.
>
> ---------------------------------------------------------------
> Some nits:
>
> MOBIKE allows both parties to have several addresses, and there are
>   up to N*M pairs of IP addresses that could potentially be used.  The
>   decision of which of these pairs to use has to take into account
>   several factors.  First, the parties have may preferences about which
>   interface should be used, due to performance and cost reasons, for
>   instance.  Second, the decision is constrained by the fact that some
>   of the pairs may not work at all due to incompatible IP versions,
>   outages somewhere in the network, problems at the local link at
>   either end, and so on.
>
> How about changed text indicated by *:
>
> MOBIKE allows both parties to have *multiple points of attachment each
> represented by an IP address*, and there are
>   up to N*M pairs of IP addresses that could potentially be used *for
> the tunnel endpoints*.  The
>   decision of which of these pairs to use has to take into account
>   several factors.  First, the parties have *many* preferences about
> which
>   interface should be used, due to performance and cost reasons, for
>   instance.  Second, the decision is constrained by the fact that some
>   of the pairs may not work at all due to incompatible IP versions,
>   outages *delete somewhere* in the network, problems at the local link
> at
>   either end, and so on.
>
> -- Maureen
>
>
>
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Monday, October 03, 2005 10:21 AM
> To: [email protected]
> Subject: [Mobike] Issue list status & plea for help
>
> I have now marked all the issues on the issue list as closed.
> If we re-visit any of the topics later (which hopefully we don't),
> they will get new issue numbers.
>
> A couple of pleas for help from the issue list maintainer:
>
> - If you have many comments, please send them in several
>  messages; this makes it much easier to track their status!
>  Of course, not every typo needs a separate message, but if
>  you have more than, say, 50 lines of comments, please split
>  them.
>
> - Be constructive: just pointing out problems or saying "I didn't
>  understand Section X.Y" is not forbidden, but it's much better
>  to say what you would like to see changed in the document.  Do
>  you want a technical change in the protocol, or just rewording
>  the description? Adding new functionality to the protocol?
>  Or perhaps you don't want any changes, but are just asking a
>  question about the protocol? (sometimes it's not easy to tell
>  these apart)
>
> Best regards,
> Pasi
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike