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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

The IESG-3
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.

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

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

Devarapalli, Vijay
Hello,

Good job to the design team that worked on this and all the folks who
were involved in this document later on.

Vijay

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of The IESG
> Sent: Wednesday, February 04, 2009 7:34 AM
> To: IETF-Announce
> Cc: mipshop mailing list; Internet Architecture Board;
> mipshop chair; RFC Editor
> Subject: [Mipshop] Protocol Action: 'IEEE 802.21 Mobility
> Services Framework Design (MSFD)' to Proposed Standard
>
> 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-so
> lution-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.
>
> _______________________________________________
> Mipshop mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/mipshop
>
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop