Document: draft-ietf-mipshop-mstp-solution-06
Reviewer: David L. Black
Review Date: September 18, 2008
IETF LC End Date: September 18, 2008

Summary:
This draft is on the right track, but has open issues, described in the review.

Comments:

This is a generally well-written draft about mobility handoff discovery and transport.  I found a number of things that need attention, but none of these appear to be show-stoppers.  The primary open issues are in Section 6 on Transport Options.

Section 3 should discuss relationship to deployment scenarios in Section 4 of RFC 5164.  I believe this draft covers the IP transport portions of the scenarios described in Sections 4.1 and 4.2 of RFC 5164.

The following paragraph at the end of Section 5 should also be summarized in the Security Considerations section:

   It should be noted that authorization of a MN to use a specific MoS
   server is neither in scope of this document nor is currently
   specified in [IEEE80221].  We further assume all devices can access
   discovered MoS.  In case future deployments will implement
   authorization policies the mobile nodes should fall back to other
   learned MoS if authorization is denied.

Section 5.2 says:

   To discover an MoS in the visited network, the MN SHOULD attempt to
   use the DHCP options for MoS discovery

No other alternative is described.  Why is this a "SHOULD"
requirement instead of "MUST"?  Is it possible that the MN doesn't know whether it's in a home vs. visited network, but wants to find an MoS in whatever network it's attached to?

The message size discussion in Section 6.1 seems rather cavalier about problems caused by large messages.  The following line of reasoning appears to be implicit in Section 6.1 and should be made explicit:
- IP fragmentation SHOULD NOT be used (e.g. consequences of loss
	of one IP fragment that are already described).  RFC 4963
	can be cited as a reason to completely disable IP
	fragmentation if that's helpful.
- That leaves a choice between TCP and UDP.
- Messages larger than the PMTU size cannot use UDP (there's
	already a MUST for a message size limit).
- Therefore messages large than the PMTU size SHOULD use TCP.

The last paragraph of Section 6.1 criticizes TCP on the grounds of latency and possible splitting of a higher level message across segments.  SCTP (RFC 4960) addresses both of these problems, and therefore needs to be mentioned and cited, but it's probably ok to set SCTP aside as not widely deployed in the infrastructure and devices to which this document applies (i.e., absence of "running code").

Section 6.2 on message frequency says:

   On the other hand, if UDP
   is used, a rate-limiting effect similar to the one obtained with TCP
   may be obtained by adequately adjusting the parameters of a token
   bucket regulator as defined in the MIH specifications [IEEE80221].

This is important - I think that "may" ought to be a "SHOULD".

One of the recommendations for parameter adjustment is:

   o  If MIHF knows the RTT, the rate can be based upon this

Explain how to base the rate on the RTT, and what "knows the RTT"
means in the presence of congestion-induced delays.

Section 6.3 on retransmission says:

   The default
   number of retransmissions is set to 2 and retransmissions are
   controlled by a timer with a default value of 10s.  

Those values appear to be reasonable.  Please say that they SHOULD be used, possibly with some qualification involving network-specific characteristics.

In Section 6.5, given that IS messages are the main (only?) source of large messages and IS messages do not have tight latency requirements that favor UDP for CS and ES messages, would it be appropriate to say that TCP SHOULD be used for IS messages?

The operational scenario in Section 7 is useful, but the diagram size is enormous (over a page).  Would it be reasonable to shrink it to fit on one page by combining each MIH User - MIHF interaction into the line for the communication that the interaction is part of?

Section 8 mentions "underlying link layer security".  Please provide an example (an IEEE 802 example would be very relevant).

idnits 2.09.00 found a couple of possible nits.  These are minor, as the dns-discovery draft is intended for standards track:

  == Outdated reference: A later version (-05) exists of
     draft-ietf-mipshop-mos-dhcp-options-03

  -- Possible downref: Normative reference to a draft: ref.
     'I-D.ietf-mipshop-mos-dns-discovery'  (No intended status found in state
     file of draft-ietf-mipshop-mos-dns-discovery)