Subject: [rtcweb] Review of ip-handling

From: Martin Thomson <[email-masked]>
Date: Wed, 10 May 2017 11:46:16 +1000

In Section 3, please don't imply that WebRTC is only for privacy.  At
a minimum "Being peer-to-peer, WebRTC represents a technology that
could improve privacy,"  Though I'd avoid this sort of statement
altogether.  One interesting side effect of unintermediated or
peer-to-peer communications is that there is now network-level
metadata showing who was communicating.  There is a direct flow
between peers.  The privacy gain (no single middleman with access to
communications metadata) becomes a potential loss (passive network
observers can see who was talking more easily).

I think that Section 3 could be more simply stated as:

Provide a framework for understanding the problem so that controls
might be provided to make different trade-offs regarding performance
and privacy concerns with WebRTC.  Using that framework, define
settings that enable peer-to-peer communications each with a different
balance between performance and privacy.  Finally, provide
recommendations about settings that provide reasonable performance
without also exposing addressing information in a way that might
violate user expectations.

In Section 4, the mention of RETURN isn't really necessary and it will
stall progress of this draft.  The framing of RETURN ensures that it
falls into the "proxy" definition quite neatly, so it will work
without changing this draft.  Though RETURN would reduce the
performance downsides of the higher-numbered modes - significantly -
it doesn't really need a special mention here.

I'm not very enthusiastic about this bullet in Section 5:

   o  Future versions of browsers may present an indicator to signify
      that the page is using WebRTC to set up a peer-to-peer connection.
      Applications MUST only use WebRTC in a fashion that is consistent
      with user expectations.

The indicator thing is kinda speculative; based on my experience with
these things, I'd say that the chances that we did that would be close
to zero.  Also, the MUST here is completely toothless to the point
that I think it's dangerous.  Applications will care to the extent
that they care, and yelling at them isn't going to influence that one
iota.

Also, since the whole point of this document is to establish a
framework for thinking about this specific problem, I think that it's
safe to remove this sentence.  I would remove the entire bullet point.

Nits:

Many of the references need to have a space after the closing bracket.

Remove the reference to 8.8.8.8.  It's actually a good example, but
it's not necessary and it is likely to cause some people's heads to
explode.  As much as I might personally enjoy that, it's not my
document; you might be better avoiding this.