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

From: Datatracker on behalf of Benjamin Kaduk <[email-masked]>
Date: Wed, 06 Mar 2019 18:51:44 -0800

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.

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

---

From: Justin Uberti <[email-masked]>
Date: Thu, 7 Mar 2019 15:37:17 -0800

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/

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.

> to find "getUserMedia consent".

Noted.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 9 Mar 2019 12:27:18 -0600

> 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