Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12

Christer Holmberg <> Mon, 16 October 2017 10:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDE3D1321A2; Mon, 16 Oct 2017 03:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 52WNGP5J51L0; Mon, 16 Oct 2017 03:03:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 038411321CB; Mon, 16 Oct 2017 03:03:13 -0700 (PDT)
X-AuditID: c1b4fb3a-1c7889c000006897-f6-59e483e018f1
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 62.E1.26775.0E384E95; Mon, 16 Oct 2017 12:03:12 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0352.000; Mon, 16 Oct 2017 12:02:09 +0200
From: Christer Holmberg <>
To: Harald Alvestrand <>, "" <>
CC: "" <>
Thread-Topic: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12
Thread-Index: AQHTQRqIopdqNKi4M0G7+rZLE/Y/d6LmXBGA
Date: Mon, 16 Oct 2017 10:02:09 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7ge6D5ieRBjO6hSyO9XWxWXy7UGux 9l87uwOzx5UJV1g9liz5yRTAFMVlk5Kak1mWWqRvl8CV0X9rMmvBRaGKl3eusjYwfuPrYuTk kBAwkZh+9B9TFyMXh5DAEUaJxtVb2CCcJYwSTVN/MXYxcnCwCVhIdP/TBmkQEfCW+Pi5lQnE ZhZQl7iz+Bw7iC0s4CjR8aSdGaLGSaL30U1WCNtIYvaHC8wgY1gEVCX+7HMBMXkFrCX+X8wG qRAScJDY/vc/C0iYE2hK53JBkDCjgJjE91NroBaJS9x6Mp8J4mIBiSV7zjND2KISLx//A1sk KqAnseHEbXaIuKJE+9MGRohePYkbU6ewQdjWEncnvWSGsLUlli18DWbzCghKnJz5hGUCo/gs JOtmIWmfhaR9FpL2WUjaFzCyrmIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjLiDW35b7WA8 +NzxEKMAB6MSD29z1pNIIdbEsuLK3EOMEhzMSiK8ek1AId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rwO+y5ECAmkJ5akZqemFqQWwWSZODilGhgX/ZRseR2feuZ6fs757cu7Vs1i98vyDQxo/92z 0059ss2C9yuv/7mS/3kl/y/uB3Ztz72/X+7QqH3OeXBlEd+XT988GTbuWHBxrp/lp/VOJ7e/ T3EL2ZXnyt4gYxedqTPttKTGEq91D9VvOEau705PnJRQ/2XB68oaneuhUpYLWR/raAbOZAlV YinOSDTUYi4qTgQAm5fmBbQCAAA=
Archived-At: <>
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Oct 2017 10:03:16 -0000

Hi Harald,

Some feedback on your comments.

>Most important points:
>* The protocol has been designed and revised to be usable with non-media
>data, but the introduction and abstract do not reflect this. Expunging
>the media bias from the body of the document is probably not worth it,
>but the intro and abstract should mention it.

We COULD do a search/replace operation, and replace ³media² with ³data².
We would end up with terms like ³data stream², ³data packets² etc, but I
guess that it would be ok.

In the ³data definition² we would then describe that data includes both
RTP and non-RTP data.

>* Security considerations should mention the problem that ICE reveals
>addresses that might otherwise remain hidden, and that this is a privacy

I would be glad if someone could provide text for that, to make sure we
get it right.

>* The document has removed all the SDP specific parts (good), but the
>requirements it places on the negotiation mechanism aren¹t collectively
>documented anywhere. A section describing this would help comprehension
>for people developing signalling protocols for use with ICE.

I can think of the following requirements:

REQ: There MUST be a mechanism for ICE agents to determine whether the
remote peer supports ICE

REQ: There MUST be a mechanism for ICE agents to exchange candidate

REQ: There MUST be a mechanism for ICE agents to indicate an ICE restart
to the remote peer

>* The definition of ³component² talks about a component having one
>address. I believe that in current usage, it should be defined to have
>an address pair. (non-symmetric RTP is dead).

Or, should we say ³having one candidate pair²?

<t hangText="Component:"> A component is a piece of a data stream
requiring a candidate pair; a data stream may require
multiple components, each of which has to work for the data stream as
a whole to work.  For media streams based on RTP, unless RTP and RTCP
are multiplexed in the same port, there are two components per media
stream -- one for RTP, and one for RTCP.</t>

Regarding non-symmetric RTP, the spec says that the selected candidate
pair MUST be used for sending and receiving media, so I guess that means
symmetric RTP. Perhaps it would be good to point that out.