Re: [Ice] Tsvart last call review of draft-ietf-ice-pac-03

[Yoshifumi Nishida <[e-mail]>]

Hi Justin,

Thanks for the response.
I put my comments in lines.

On Sun, Jan 19, 2020 at 7:06 PM Justin Uberti <[e-mail]> wrote:

>
>
> On Sun, Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker <
> [e-mail]> wrote:
>
>> Reviewer: Yoshifumi Nishida
>> Review result: Almost Ready
>>
>> This document has been reviewed as part of the transport area review
>> team's
>> ongoing effort to review key IETF documents. These comments were written
>> primarily for the transport area directors, but are copied to the
>> document's
>> authors and WG to allow them to address any issues raised and also to the
>> IETF
>> discussion list for information.
>>
>> When done at the time of IETF Last Call, the authors should consider this
>> review as part of the last-call comments they receive. Please always CC
>> [e-mail] if you reply to or forward this review.
>>
>> Summary:
>>    This document is straightforward and almost ready for publication,
>>    but it will be better to clarify the following points.
>>
>> 1: How to calculate the PAC timer is not very clear to me.
>>    Does this draft recommend to use the equation described in Section
>> 14.3 of
>>    RFC8445 or are there other ways? I think this would be better to be
>>    clarified.
>>
>
> Yes, the equation in 14.3 coupled with the STUN backoff guidance in
> https://tools.ietf.org/html/rfc5389#section-7.2, although these values
> are just recommendations. The point here is to say that whatever is used
> for the check timeouts should also be used for the PAC timer.
>

Right. I was just wondering that it might be useful to mention the
recommended value can be calculated from the equation.
If the readers know what'll be the recommandation value, I think they can
have some ideas about whether their values are conservative or aggressive.


>
>> 2: I presume this draft only focuses on UDP candidates, but I think
>> clarifying
>> it would be useful.
>>    I am also wondering how to treat PAC timer if agents have a mix of TCP
>> and
>>    UDP candidates.
>>
>
> The guidance here applies to both UDP and TCP candidates. It would not be
> unheard of for a server to only offer TCP candidates, and the client to
> offer zero candidates, as in S 3.1.
>

I see. But, in this case, will there be a need to update RFC6544?
Also, if we set PAC timer around 500 msec but establishing a TCP connection
takes longer than it, should it be considered failed or not?
--
Yoshi