Skip to main content

Mobility with Traversal Using Relays around NAT (TURN)
draft-ietf-tram-turn-mobility-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: tram-chairs@ietf.org, "Simon Perreault" <sperreault@jive.com>, sperreault@jive.com, spencerdawkins.ietf@gmail.com, draft-ietf-tram-turn-mobility@ietf.org, "The IESG" <iesg@ietf.org>, rfc-editor@rfc-editor.org, tram@ietf.org
Subject: Protocol Action: 'Mobility with TURN' to Proposed Standard (draft-ietf-tram-turn-mobility-09.txt)

The IESG has approved the following document:
- 'Mobility with TURN'
  (draft-ietf-tram-turn-mobility-09.txt) as Proposed Standard

This document is the product of the TURN Revised and Modernized Working
Group.

The IESG contact persons are Mirja Kühlewind and Spencer Dawkins.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/


Ballot Text

Technical Summary

The intent of this document is to define a mechanism for TURN allocations to
survive a client IP address change. A new "mobility ticket" attribute allows the
client to migrate to a new IP address using a make-before-break approach.

The requested publication type is Proposed Standard because new TURN attributes
and behavior are defined.

Working Group Summary

The draft was discussed actively in the MMUSIC working group, under the name
MICE, before it was refocused and transferred to TRAM. Once in TRAM there were
few iterations: the WG was roughly happy with the document as it was. A few good
reviews were done by core WG members which resulted in small changes.

Document Quality

Interest in this document has been medium. The mechanism for TURN makes sense
but there are a number of other layers in a SIP/WebRTC stack at which IP address
mobility could be implemented, e.g., trickle ICE, re-INVITE, etc. At this moment
there is no single agreed-upon "how IP address mobility shall be accomplished"
vision and implementations have not yet picked a clear winner. Since the draft
was first proposed in MMUSIC a sort of "wait and see" response had been slowing
progress.  Today it seems like there won't be a clear decision and the consensus
is that publishing the TURN mechanism is what makes most sense at this point.

Personnel

Document shepherd: Simon Perreault <sperreault@jive.com>
Responsible Area Director: Spencer Dawkins <spencerdawkins.ietf@gmail.com>

RFC Editor Note