Re: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, Mar 07, 2019 at 03:37:17PM -0800, Justin Uberti wrote:
> On Thu, Mar 7, 2019 at 1:49 AM Datatracker on behalf of Benjamin Kaduk <
> [e-mail]> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-rtcweb-ip-handling-11: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I agree with Ben about the STUN/TURN normativity.
> >
> > Section 5.1
> >
> >    2.  By default, WebRTC should be able to negotiate direct peer-to-
> >        peer connections between endpoints (i.e., without traversing a
> >        NAT or relay server).  [...]
> >
> > I'm not sure how to interpret "be able to", here, with respect to
> > "without traversing a NAT", since if one endpoint is behind a NAT w.r.t.
> > the public Internet, that's not possible.
> >
> 
> There is an implicit "where possible" here. The specific scenario is for
> two devices behind the same NAT who could communicate directly if only they
> knew each others' addresses; in this case, a direct connection should be
> possible, which implies that there needs to be some way for the two sides
> to share their machine addresses. Naturally, devices behind different NATs
> will not be able to do this.

Maybe we can think about tighter wording to use here.  I'm not sure if just
using "hairpin NAT" instead of "NAT" would be (1) correct and (2) good
enough; we could also make the "where possible" explicit instead of
implicit.  But I don't feel a need to have a say in the final wording --
that can be between you and the responsible AD.

-Benjamin

> 
> > Section 5.2
> >
> >    Mode 1 MUST only be used when user consent has been provided.  The
> >    details of this consent are left to the implementation; one potential
> >    mechanism is to tie this consent to getUserMedia consent.
> >
> > nit: we may not have left a big enough breadcrumb trail for the reader
> > to find "getUserMedia consent".
> >
> 
> Noted.