Subject: [Gen-art] Gen-ART review of draft-ietf-mipshop-mstp-solution-06

From: [email-masked]
Date: Thu, 18 Sep 2008 17:51:22 -0400

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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Sep 2008 10:30:43 +0200

Thanks for your review. Authors, could you respond to David's comments, 
and possibly suggest revisions of your text based on them?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Sep 2008 13:19:42 +0200

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-masked] 
> <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]> wrote:
>
>         Please resolve these comments along with any other Last Call
>         comments you may receive.
>
>         [email-masked] <mailto:[email-masked]>      
>          Mobile: +1 (978) 394-7754

---

From: Telemaco <[email-masked]>
Date: Fri, 19 Sep 2008 12:41:08 +0200

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-masked]> wrote:

> Thanks for your review. Authors, could you respond to David's comments, and
> possibly suggest revisions of your text based on them?
>
> Jari
>
>
>> I have been selected as the General Area Review Team (Gen-ART) reviewer
>> for this draft (for background on Gen-ART, please see
>> Please resolve these comments along with any other Last Call comments you
>> may receive.
>>