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

Justin Uberti <> Mon, 20 January 2020 03:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E74C120026; Sun, 19 Jan 2020 19:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vekr_PR05Jy1; Sun, 19 Jan 2020 19:06:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57701120024; Sun, 19 Jan 2020 19:06:09 -0800 (PST)
Received: by with SMTP id w1so32247101ljh.5; Sun, 19 Jan 2020 19:06:09 -0800 (PST)
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=9p7MeptcT+0EvEFXEsbgpaHwXELh61K8VfGPs5seujA=; b=LEsuq19Xrvc9cbPThW4H9teYk0EoY1Uz0QNSwwYMt/cbzYjrEtz1zbP47eDkigu58R Cdeezw5MAy1ofIqwVO8NAAIKStksBSew972A3SUqUJ//ZHjQD78i7Z+0kyb2NKqBJfyD xtGOhHdCuf0gSXPN75230ABfCoaPQqasKNhlM4jLVE4LwKjmnyktf6540Nb2HKEWI5Z+ F9SNi4qO3Dz0Z2GW1y71MCFMJmR6NExq6YP1wrbIKTHxb8WUf7oFK1tKEYXj8SL2jVMc atBkoP6ccyzaPVK8OfkqYWEjX2bsYylwOBFuW/SuHrwvqvfb3nKnuw6EePMmzfCPx1ON lQWA==
X-Gm-Message-State: APjAAAUXPr+yzehFanKrknDdp+PikHnYaiuqUZ0GcgZ4Rf47QWqHtn4K eNS/j+uNgUQekVy8P++afwiq4MfGN6lDCIYdIJU=
X-Google-Smtp-Source: APXvYqzdipDKHptJEZKBm/4TJ+9RUPPAcxUiIeoCJD1Jfu1BpjsuR4fBzTTkV63ZA1lNSxGbQpsy1HCotmxuTGEIVtE=
X-Received: by 2002:a2e:910b:: with SMTP id m11mr11840997ljg.213.1579489567342; Sun, 19 Jan 2020 19:06:07 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Justin Uberti <>
Date: Sun, 19 Jan 2020 19:05:51 -0800
Message-ID: <>
To: Yoshifumi Nishida <>
Content-Type: multipart/alternative; boundary="000000000000968355059c89924d"
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: Mon, 20 Jan 2020 03:06:11 -0000

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.

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