Protocol Action: 'IEEE 802.21 Mobility Services Framework Design (MSFD)' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'IEEE 802.21 Mobility Services Framework Design (MSFD) '
   <draft-ietf-mipshop-mstp-solution-12.txt> as a Proposed Standard

This document is the product of the Mobility for IP: Performance, 
Signaling and Handoff Optimization Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-12.txt

Technical Summary

  This document describes a solution for discovering IEEE 802.21 
  Media Independent Handover (MIH) servers (called the MoS server) 
  and a transport layer mechanism for the reliable delivery of MIH 
  messages.

Working Group Summary

  This is an output from the MIPSHOP WG.

  The MIPSHOP WG received numerous liaison statements from the 
  IEEE 802.21 WG supporting this work. The solution described in 
  the document is supposed to provide a Layer 3 protocol for 
  transport of the handover assist information. The IEEE 802.21
  WG also provided the requirements for the solution.

Document Quality

   This specification has been reviewed by Jari Arkko for the IESG.

   There are no known implementations.

Personnel

   Document shepherd: Vijay Devarapalli
   Responsible AD: Jari Arkko

RFC Editor Note

  Please replace the first paragraph of Section 6.5 with this:

   The ES and CS messages are small in nature and have tight latency
   requirements. On the other hand, IS messages are more resilient in
   terms of latency constraints and some long IS messages could exceed
   the MTU of the path to the destination. TCP SHOULD be used as the
   default transport for all messages. However, UDP in combination
   with MIH acknowledgement SHOULD be used for transporting ES and CS
   messages that are shorter than or equal to the path MTU as
   described in Section 6.1.


IESG Note

  Please add the following IESG note to the document:

   As described later in this specification, this protocol does not
   provide security mechanisms. In some deployment
   situations lower layer security services may be sufficient.
   Other situations require proprietary mechanisms
   or as yet incomplete standard mechanisms, such as
   the ones currently considered by IEEE. For these reasons, the
   specification recommends careful analysis before considering any
   deployment.

   The IESG emphasizes the importance of these
   recommendations. The IESG also notes that this specification
   deviates from the traditional IETF requirement that support
   for security in the open Internet environment is a mandatory
   part of any Standards Track protocol specification. An exception
   has been made for this specification, but this should not be
   taken to mean that other future specifications are free from
   this requirement.