Re: [tram] Suresh Krishnan's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT)

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

> -----Original Message-----
> From: Suresh Krishnan [mailto:[e-mail]]
> Sent: Thursday, September 1, 2016 9:15 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Simon Perreault
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Subject: Suresh Krishnan's No Objection on draft-ietf-tram-turn-mobility-05:
> (with COMMENT)
> 
> Suresh Krishnan 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:
> ----------------------------------------------------------------------
> 
> * Section 3
> 
> In the figure (without number/title) why is there an Allocate failure in the
> second message? I could not find the associated text.

Added title and number to figure, and associated text:

   In Figure 1, the client sends an Allocate request with an MOBILITY-
   TICKET attribute to the server without credentials.  Since the server
   requires that all requests be authenticated using STUN's long-term
   credential mechanism, the server rejects the request with a 401
   (Unauthorized) error code.  The client then tries again, this time
   including credentials (not shown).  This time, the server accepts the
   Allocate request and returns an Allocate success response and a
   ticket inside the MOBILITY-TICKET attribute.  Sometime later, the
   client IP address changes and decides to refresh the allocation and
   thus sends a Refresh request to the server with MOBILITY-TICKET
   attribute containing the ticket it had received from the server.  The
   refresh is accepted and the server replies with a Refresh success
   response and a new ticket inside the MOBILITY-TICKET attribute.

> 
> * Section 3.2.1
> 
> The section on sending a Refresh when the IP address does not change needs
> a little bit more tightening. Given that the server would reject the request with
> a mobility ticket in this case, it would be good to put in an explicit restriction
> to not add the mobility ticket in the following statement
> 
> OLD:
> If a client wants to refresh an existing allocation and update its time-to-expiry
> or delete an existing allocation, it will send a Refresh Request as described in
> Section 7.1 of [RFC5766]
> 
> NEW:
> If a client wants to refresh an existing allocation and update its time-to-expiry
> or delete an existing allocation, it MUST send a Refresh Request as described
> in Section 7.1 of [RFC5766] and MUST NOT include a MOBILITY-TICKET
> attribute.

Thanks, updated.

-Tiru

>