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

From: "Suresh Krishnan" <[email-masked]>
Date: Wed, 31 Aug 2016 20:44:37 -0700

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.

* 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.

---

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

> -----Original Message-----
> From: Suresh Krishnan [mailto:[email-masked]]
> Sent: Thursday, September 1, 2016 9:15 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Simon Perreault
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Suresh Krishnan'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.)
> 
> 
> 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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 1 Sep 2016 04:43:49 +0000

Thanks Tiru for taking care of both the points. The proposed 
changes/additions look good to me.

Regards
Suresh