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

From: Harald Alvestrand <[email-masked]>
Date: Sun, 3 Apr 2016 00:51:59 +0200

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.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 4 Apr 2016 19:08:31 -0700

Thanks for the concrete feedback. I agree with the proposed direction.

On Sat, Apr 2, 2016 at 3:51 PM, Harald Alvestrand <[email-masked]>
wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 5 Apr 2016 14:32:43 +0200

+1

-- 
Victor Pascual Ávila

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 5 Apr 2016 14:19:23 +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.

Regards

Keith

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

+1

On Tue, Apr 5, 2016 at 4:08 AM, Justin Uberti <[email-masked]> wrote:
>> imperative, normative language, an implementation can claim support 
>> for RFC XXXX and expect the statement to be understood.
>> - Add the RFC 2119 incantation, including Stefan's addition 
>> ("lowercase words mean what they usually do")
>>
>> - 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.
>> I think this would make the spec a more useful tool for specifying 
>> what an application does.
>>
>>
>>
>> --

--
Victor Pascual Ávila