Hello, We will address David's comments. Shall we just propose modified text or also produce a new draft version?
telemaco On Fri, Sep 19, 2008 at 10:30 AM, Jari Arkko <[EMAIL PROTECTED]> wrote: > Thanks for your review. Authors, could you respond to David's comments, and > possibly suggest revisions of your text based on them? > > Jari > > > [EMAIL PROTECTED] wrote: > >> 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
