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

Yoshifumi Nishida <> Tue, 21 January 2020 06:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6041B120071; Mon, 20 Jan 2020 22:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LkyNkSPn2Gwd; Mon, 20 Jan 2020 22:42:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA3E1120045; Mon, 20 Jan 2020 22:42:45 -0800 (PST)
Received: by with SMTP id s16so1059663vsc.10; Mon, 20 Jan 2020 22:42:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W6BcBkK0XcRhVv/Fm9Wew32waehkWlhTX8Z4/G90I3A=; b=ZIiUb1PtLWC53oNKjXEXRodZY4FBX2RSOgCafGYjXy8LVAR50MlHAHnWX1PHZC3Xbd 3HXO2U481e8+Iyb3EJa1tpTstJlHpxWLOXBwo3tHuvKqq6JQrFiOgCCqE9hbIEsxQ46s lnfi+mLBdT4ew522vK5nJ/aM/0KOLeKBC676/3YuUj1PJyJ7YOjl/OSCRoF5rXy7K4ET rPKtpynzJeiX/LoP/H7JiEze7hkiu3xDFmsO2M1QOWTYM/8G5CDWpxnOdWlAHtJ3OU+J C935qrA1jD1tjp77cSCJjOsXLLmw3TAomvwuyhjnrV9iRnnC02DuRfzXPzC3L8TiT0vB yw2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W6BcBkK0XcRhVv/Fm9Wew32waehkWlhTX8Z4/G90I3A=; b=ieeryoYNn3Kc9eJ8aFJEa3RNZuONdlErIxvVtS4zHVtDrtC3exBq+/ELPk7pVJsU+4 eupvtzOSUi8ymnq51XhrsWeAMyhPXdobvpM3RQRYNL2Wm1PDwhIigL158mskcbNI6vAk KhsexkLY/AmQYmIOh31gQG1FizsLURv943VLF2FGyABfEG5zuLO2qvFQ/KE+zV8EG4qI +UPIfmjso6od5tNb1q2nvOT0t2CFlkUHoxKIv7zQrm/YMnx1ml0z38rXkM0bbzEqgBDY MXGs9w248B6TlaedspogrL/Ni9bgo5jVzS4yFyOBkMTWSvjljeZjp/bk/Ewp2p/7xDxp H7Bg==
X-Gm-Message-State: APjAAAXSjwZbOs1eydlx1Ux+SrK5V9UnPtDQG1n63UEYLlT33xIIMGhl 1WGh7PBcIBPdN/krjZzgK4FUSZM0uw/YLHqmUPE=
X-Google-Smtp-Source: APXvYqwiM9PU0vRItqgKAjWQMmjpPJDpcYUZtqNM6XtHhMGVIC+Inic0MJ88oJxiXQ9Ftp3nckiiOYELrnGQpOeIanM=
X-Received: by 2002:a67:ec88:: with SMTP id h8mr1742839vsp.65.1579588964829; Mon, 20 Jan 2020 22:42:44 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Yoshifumi Nishida <>
Date: Mon, 20 Jan 2020 22:42:33 -0800
Message-ID: <>
To: Justin Uberti <>
Content-Type: multipart/alternative; boundary="00000000000023cef6059ca0b7e2"
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-ice-pac-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jan 2020 06:42:49 -0000

Hi Justin,

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

On Sun, Jan 19, 2020 at 7:06 PM Justin Uberti <> wrote:

> On Sun, Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker <
>> 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
>> 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
>> 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
>, 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?