Re: [rtcweb] tweaks for ip-handling language

I generally agree with Martin's comments, with the following exception.

I would remove everything after "off getUserMedia consent." It has no
normative effect
and is simply rationale.

-Ekr

On Thu, Nov 17, 2016 at 8:26 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> This looks like a good change on its own.  However, reading the
> document, I find that the "all possible candidates" issue is hard to
> fix.  This text is part of the rationale for the different modes.
> Placing a requirement here - before we've established the baseline -
> is probably the wrong thing to do.
>
> I think that restructuring the corresponding section might be the best
> plan.  The text in question isn't rationale; it doesn't really belong
> where it is.
>
> Thus, I would recommend this structure:
> 1. define the 4 modes
> 2. recommend that mode 2 is the default.
> 3. include this text - tweaked slightly - to explain how user consent
> is necessary to use mode 1
> 4. explain that modes 3 and 4 might be made the default in certain contexts
> 5. include the other rationale to justify the design
>
>
> On 16 November 2016 at 16:25, Alissa Cooper <alissa@cooperw.in> wrote:
> > This still needs the fix for “all possible candidates.”
> >
> > OLD
> > Gathering all possible candidates SHOULD only be performed when some
> form of user consent has been provided; this thwarts the typical drive-by
> enumeration attacks.  The details of this consent are left to the
> implementation; one potential mechanism is to key this off getUserMedia
> consent.  The getUserMedia suggestion takes into account that the user has
> provided some consent to the application already; that when doing so the
> user typically wants to engage in a conversational session, which benefits
> most from an optimal network path, and lastly, the fact that the underlying
> issue is complex and difficult to explain, making explicit consent for
> enumeration troublesome.
> >
> > NEW
> > Gathering all possible candidates MUST only be performed when some form
> of user consent has been provided; this thwarts the typical drive-by
> enumeration attacks.  The details of this consent are left to the
> implementation. One potential mechanism is to tie this consent to
> getUserMedia consent. Such a mechanism might be chosen based on the fact
> that the user has provided some consent to the application already; that
> when doing so the user typically wants to engage in a conversational
> session, which benefits most from an optimal network path, and lastly, the
> fact that the underlying issue is complex and difficult to explain, making
> explicit consent for enumeration troublesome.
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>