Re: [Mobopts] MPA review

[Ashutosh Dutta <[e-mail]>]

Rajeev, Madjid,
                 Thanks for your review and comments on the MPA draft. 
We will submit a revised version addressing your comments and suggestions.

Regards
Ashutosh

Koodli, Rajeev wrote:
> 	 
> Hi,
> 
> my high-level comment is that the document captures many things. While
> this is a good thing in one way, it diminishes the focus as a bye
> product, unfortunately. So, I am suggesting that it should be
> streamlined to make it crisp to better retain its focus on pre-auth
> related issues, framework and procedures for inter-domain handovers.
> 
> More comments below:
> 
> Regards,
> 
> -Rajeev
> 
> 
> The paragraph starting with "An end-to-end delay consists of several.."
> is too dense and long. I am not sure if all of the text is needed.
> Please consider making this brief, and keep only the parts which are
> essential. In general, detailed descriptions of the previous work should
> be referenced out, and not be repeated here.
> 
> "This type of Inter-technology handover is often
>    called as Vertical Handover since the mobile makes movement between
>    two different cell sizes."
>                       ^^^^^^^^^^ ??
> Section 2 is titled "Inter-domain handover", but it includes the
> definitions for different types of handovers. Perhaps revise the section
> heading to something like "Handover Types". Also, please provide more
> succinct definitions. You may move details which may be useful (but not
> crucial) to an Appendix.
> (I am trying to see if we can make the presentation little more
> crisper).
> 
> Section 3 provides a good survey. You may want to revise the title to
> "Related Work"
> 
> Section 4 - Applicability should be no more than two paragraphs I think
> 
> Shouldn't the Terminology Section be earlier, say right after
> Introduction?
> 
>  Section 6.1:
> "MPA provides four basic procedures to provide this functionality.
>    The first procedure is referred to as "pre-authentication", the
>    second procedure is referred to as "pre-configuration", the
>    combination of the third and fourth procedures are referred to as
>    "secure proactive handover"."
> 
> Either state 4 procedures or 3 procedures.
> 
> Section 6.1, paragraph 3 is important for people to get a high-level
> overview. It is too condensed. Please try to make the steps clear. And,
> do no use acronyms (such as MMP) that are not defined earlier.
> 
> PHT (Proactive Handover Tunnel) -> Proactive Handover Tunnel (PHT)
> 
> Section 6.2:
> 
> "..securely executing a configuration protocol to
>    securely deliver an IP address .."
> 
> too many 'securely'
> 
> "An access router is a router that is responsible for the other part
>    of pre-configuration, i.e., securely executing a tunnel management
>    protocol to establish a proactive handover tunnel to the mobile node.
>    The signaling messages of the configuration protocol MUST be
>    protected using a key derived from the key corresponding to the
>    MPA-SA."
> 
> May be I missed it.. How does the AR get the corresponding keys? You
> describe it later, but please make a reference
> 
> Section 6.3:
> 
> Step 2: "It then performs pre-configuration,
>    with the configuration agent using the configuration protocol to
>    obtain an IP address, say nCoA (new care-of address), and other
>    configuration parameters from the CTN, and with the access router
>    using the tunnel management protocol to establish a proactive
>    handover tunnel.  "
> 
> There are two distinct steps here: pre-configuration, tunnel set up.
> You should not combine them into a single sentence (this applies as a
> general rule). Also, specify what "other configuration parameters"
> mean; it should be clear.
> 
> Step 4:
> "The mobile may execute the tunnel
>    management protocol to delete or disable the proactive handover
>    tunnel and cache nCoA after deletion or disabling of the tunnel. "
> 
>  Do you allow tunnel deletion prior to link switching? If so, what does
> the AR do for packets arriving for nCoA, once tunnel interface is
> deleted? "Caching" an address does not sound right.
> 
>  "An example call flow for MPA is shown in Figure 3 and Figure 4."
> 
> Why is this an example call flow? This is _the_ call flow right?
> 
> Section 7:
> 
> Please focus on the parts essential to the MPA, and move rest of the
> description to the Appendix.
> 
> Section 7.3.5. is perhaps not crucial, and can be moved to the appendix
> 
> Section 7.4 is not necessary I think. You have created a tunnel
> interface between the MN and AR. There are references on how to ue ND
> over tunnel interfaces. You can also disable it.
> 
> Sections 7.6 and 7.9 are related, and should be condensed into one
> section I think.
> 
> Section 7.8 does not belong to the main body of the document
> 
> Section 8 on Deployment Issues: IMHO, this may be a little early for the
> framework. I would consider a separate document once enough experience
> is obtained. If there are parts you consider worth documenting now,
> please move them to the Appendix.
> 
> Section 9 is important since it is supposed to capture the Inter-domain
> Handover, which is the primary focus of this ID.
> I would consider the key issues that come up, and move multicast
> mobility out, or considerably condense it.
> 
> In sum, please revise the ID keeping the essential parts in the main
> body, referencing known work (without too much description) and moving
> the adjoining and descriptive material you consider necessary to
> appendix.
> 
> 
> General presentation:
> 
> please revise phrases such as "A mobile may like to.." to "A mobile may
> wish to.." And, please avoid sentences such as "..should not be a big
> problem".
> 
> "Third, a mobility optimization mechanism needs to support not only
> multi-interface terminals where multiple simultaneous connectivity
> through multiple interfaces can be expected, but also single-interface
> terminals."
> 
> RKo> I assume you mean single interface connectivity right? Even with
> multiple interfaces, you could still have a single interface
> connectivity.
> 
> "References [RFC2679], [RFC2680] and 2681 [RFC2681] describe some of the
> measurement techniques for delay and
>    jitter."
> 
> RKo> "Measurement techniques for delay and jitter are described in [],
> [].."
> 
> 
> "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [e-mail] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
> _______________________________________________
> Mobopts mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mobopts
_______________________________________________
Mobopts mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mobopts