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

[Christer Holmberg <[e-mail]>]

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

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
information

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.

Regards,

Christer