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

[Suresh Krishnan <[e-mail]>]

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

Regards
Suresh

On 09/01/2016 12:11 AM, Tirumaleswar Reddy (tireddy) wrote:
>> -----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
>
>>
>
>