WebRTC IP Address Handling Requirements
draft-ietf-rtcweb-ip-handling-12

[Ballot comment]
* Section 3
  Not sure how the use of temporary addresses in IPv6 [RFC4941] is relevant at all to a discussion of NAT usage (#2). Can you please clarify?

  "#2 is a less significant but valid concern.  While the [RFC4941] IPv6
  addresses recommended by [I-D.ietf-rtcweb-transports] are fairly
  benign due to their intentionally short lifetimes"

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

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3744



COMMENTS
S 3.
> 
>      1.  If the client is multihomed, additional public IP addresses for
>          the client can be learned.  In particular, if the client tries to
>          hide its physical location through a Virtual Private Network
>          (VPN), and the VPN and local OS support routing over multiple
>          interfaces (a "split-tunnel" VPN), WebRTC will discover not only

This might be simpler if you said "route traffic over" rather than
"support routing"

Also, do you want to say "may discover" because the guidelines below
would potentially stop that.


S 6.2.
>      addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to
>      route WebRTC traffic the same way as it would HTTP traffic.  STUN and
>      TURN will work as usual, and host candidates can still be determined
>      as mentioned below.
> 
>  6.2.  Determining Host Candidates

This is framed a little confusingly, because all host candidates are
suitable in mode 1. Perhaps add "In modes XXX..."

[Ballot comment]
I agree with Mirja that this reads more like a BCP. Was BCP status considered by the WG?

(nit) §3: Please expand "RTMFP" on first mention.

(nit) §5.2: "Mode 1 MUST only be used when user consent has been provided"
Please consider "... MUST NOT be used unless user consent has been provided."

§11.2: It seems like the references for STUN and TURN should be normative.

[Ballot comment]
To me this doc reads more like a BCP.

Thanks for replying to the TSV-ART review (and thanks, Joe, for the review)! Please edit the doc accordingly.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-rtcweb-ip-handling-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-02-15):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , draft-ietf-rtcweb-ip-handling@ietf.org, rtcweb@ietf.org, sean@sn3rd.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (WebRTC IP Address Handling Requirements) to Proposed Standard


The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC IP
Address Handling Requirements'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-02-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document provides information and requirements for how IP
  addresses should be handled by WebRTC implementations.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ballot/


No IPR declarations have been submitted directly on this I-D.

Based on chair input, I'm expecting a new version of this document with a mention of future work on mdns-based approaches for gathering candidates on the local segment.

1. Summary

This draft provides information and requirements for how IP addresses should be handled by WebRTC implementations.  This is a companion draft to the two security-related draft, but it was kept separate to this draft to change more quickly. The security drafts are standards track and so is this one.

Sean Turner is the Shepherd.
Adam Roach is the responsible AD.

2. Review and Consensus

This document has been extensively reviewed both on the list at a numerous in-person WG meetings.  This document is controversial because it deals with privacy and user consent issues related to Browsers.  There are strong feels about the draft’s contents and what we have arrived at is rough consensus.

3. Intellectual Property

They have stated that to their direct, personal knowledge any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

4. Other Points

N/A