Subject: [tram] Mirja Kühlewind's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 31 Aug 2016 10:50:51 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tram-turn-mobility-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Is the following scenario worth to be discussed in the doc?

A client receives a MOBILITY-TICKET from the server but when it tries to
send a Refresh Request the server ignors the ticket and sets up a new
association (maybe because the server seemlessly migrated to a machine
that does not support/understand MOBILITY-TICKETs or because of policy
reasons) and therefore also does not send a new MOBILITY-TICKET back. I
guess in this case the client would probably still want to communication
with the destination server and just start a new transport connection,
right?

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 1 Sep 2016 02:52:52 +0000

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: Wednesday, August 31, 2016 11:21 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Simon Perreault
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Mirja Kühlewind's No Objection on draft-ietf-tram-turn-mobility-05:
> (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> A client receives a MOBILITY-TICKET from the server but when it tries to send
> a Refresh Request the server ignors the ticket and sets up a new association
> (maybe because the server seemlessly migrated to a machine that does not
> support/understand MOBILITY-TICKETs or because of policy
> guess in this case the client would probably still want to communication with
> the destination server and just start a new transport connection, right?

Yes, server will throw an error and client will have to start a new allocation.
It's an corner case, but probably worth discussing. 

I can add the following lines to Section 3.2.2: 

If the server configuration changes to forbid mobility or the server transparently fails-over to another server instance that does support MOBILITY-TICKET then the server rejects the Refresh request with a  Mobility Forbidden error code and the client starts afresh with a new allocation.

-Tiru