Re: [rtcweb] Positioning draft-ietf-rtcweb-ip-address as a standards-track document

"Drage, Keith (Nokia - GB)" <> Tue, 05 April 2016 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E78812D1A9 for <>; Tue, 5 Apr 2016 07:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S6jXKFbqbHI5 for <>; Tue, 5 Apr 2016 07:20:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DC1D12D590 for <>; Tue, 5 Apr 2016 07:20:00 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 63115AC5DF730; Tue, 5 Apr 2016 14:19:52 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id u35EJsmU009199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2016 14:19:54 GMT
Received: from ( []) by (GMO) with ESMTP id u35EJleX031034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Apr 2016 16:19:54 +0200
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 16:19:23 +0200
From: "Drage, Keith (Nokia - GB)" <>
To: "" <>, Justin Uberti <>
Thread-Topic: [rtcweb] Positioning draft-ietf-rtcweb-ip-address as a standards-track document
Thread-Index: AQHRjuAkMCUJHmT0vUyrP+9UAmfl2597LziAgAA7yFA=
Date: Tue, 05 Apr 2016 14:19:23 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [rtcweb] Positioning draft-ietf-rtcweb-ip-address as a standards-track document
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Apr 2016 14:20:08 -0000

I have no problem with the proposed changes. 

I do however have some further questions as a result of those changes.

1)	In clause 3, we have the following sentence unchanged:

	"This means that WebRTC should be configured by
   default to only reveal the minimum amount of information needed to
   establish a performant WebRTC session, while providing options to
   reveal additional information upon user consent, or further limit
   this information if the user has specifically requested this."

Section 3 is entitled goals, but I am unsure how this sentence fits in that scope. Can you clarify (in response rather than in the draft for the moment).

2)	What happens to clause 5. Is the first bullet:

	"Applications should deploy a TURN server with support for both UDP
      and TCP connections to the server.  This ensures that connectivity
      can still be established, even when Mode 3 or 4 are in use,
      assuming the TURN server can be reached."

specified elsewhere, and if so where, or is this a real "SHOULD".

3)	Similarly on clause 5, the proposed text states that mode 1 and mode 2 are mandatory to support, with the implication that mode 3 and mode 4 are optional. However clause 5 states:

	"Applications can detect when they don't have access to the full
      set of ICE candidates by checking for the presence of host
      candidates.  If no host candidates are present, Mode 3 or 4 above
      is in use."

Which seems to imply that mode 3 and mode 4 have to be supported as well.

4)	And on the last bullet of clause 5, I am unsure whether

	"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 should be careful to only use WebRTC in a fashion
      that is consistent with user expectations." 

belongs in the document. Can you provide some explanation as to why you believe it is useful.



-----Original Message-----
From: rtcweb [] On Behalf Of EXT Victor Pascual Avila
Sent: 05 April 2016 13:33
To: Justin Uberti
Subject: Re: [rtcweb] Positioning draft-ietf-rtcweb-ip-address as a standards-track document


On Tue, Apr 5, 2016 at 4:08 AM, Justin Uberti <> wrote:
> Thanks for the concrete feedback. I agree with the proposed direction.
> On Sat, Apr 2, 2016 at 3:51 PM, Harald Alvestrand 
> <>
> wrote:
>> I've read through draft-ietf-rtcweb-ip-address again, with an eye to 
>> seeing how it would read as a standards-track document.
>> As such, it seems to me to provide rather tentative language in a few 
>> places, which could be strengthened by use of the CAPITALIZED WORDS.
>> I think this is a Good Thing; if this is standards-track, with 
>> imperative, normative language, an implementation can claim support 
>> for RFC XXXX and expect the statement to be understood.
>> (Remember - there is no protocol police. Nothing forces people to 
>> support RFC XXXX.)
>> Changes needed:
>> - Add the RFC 2119 incantation, including Stefan's addition 
>> ("lowercase words mean what they usually do")
>> - Replace all occurences of "We recommend that..." with "an 
>> implementation MUST".
>> - In section 3, end of first paragraph: "   Specifically, WebRTC
>> should:" -> "Implementations of this specification will:"
>> - In section 4: "We recommend Mode 1 ... " -> "Mode 1 and mode 2 MUST 
>> be supported. Mode 1 SHOULD be the default when the user has not 
>> granted access to camera / microphone. Mode 2 SHOULD be the default 
>> when the user has granted access to camera / microphone. The 
>> implementation MAY provide means of letting the user or administrator select between modes.
>> These means MUST NOT be placed under the control of WebRTC applications."
>> I think this would make the spec a more useful tool for specifying 
>> what an application does.
>> --
>> Surveillance is pervasive. Go Dark.
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list

Victor Pascual Ávila

rtcweb mailing list