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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[e-mail]]
> Sent: Wednesday, August 31, 2016 11:21 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Simon Perreault
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Subject: Mirja Kühlewind's No Objection on draft-ietf-tram-turn-mobility-05:
> (with COMMENT)
> 
> 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?

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

>