I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
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)
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
