I think you can submit a new version. Jari
Telemaco wrote: > 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] > <mailto:[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] <mailto:[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] <mailto:[EMAIL PROTECTED]> > Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
