Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-overview-18: (with COMMENT)

From: Sean Turner <[email-masked]>
Date: Tue, 16 May 2017 12:36:31 -0400

> On Apr 24, 2017, at 22:37, Ben Campbell <[email-masked]> wrote:
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I am balloting "yes", but I have a few minor comments:
> 
> Substantive Comments:
> 
> -2.2 : 
> -- Why is a WebRTC gateway assumed to be a "compatible" endpoint rather
> than a full endpoint? I recognize a gateway is different from a typical
> end-user endpoint, but are there specific endpoint requirements that a
> gateway is not likely to meet? (Feel free to say "it's documented in the
> gateway draft...." :-) )

It’s documented in the (cough) now expired gateways draft:
https://www.ietf.org/archive/id/draft-ietf-rtcweb-gateways-02.txt
Ted’s pinged Harald to revive this one.

> -- "In this case, similar security considerations as for Javascript may
> be needed; however, since such APIs are not defined or referenced here,
> this document cannot give any specific rules for those interfaces."
> I am confused by this sentence, since I don't see any security
> considerations specific to Javascript in this draft, either.

RTCweb Javascript-related security considerations are addressed in the (cough) now expired security drafts:
https://www.ietf.org/archive/id/draft-ietf-rtcweb-security-arch-12.txt
https://www.ietf.org/archive/id/draft-ietf-rtcweb-security-08.txt
The Security Considerations points to draft-ietf-rtcweb-security, which will get you to the other draft as well.

> -7
> -- list item 2: Is it an open question whether a signaling gateway is
> needed for interacting with SIP devices?

I do not believe that item #2 (copied below) is an open question, it’s just pointing out that if you are going try to interoperate with legacy SIP devices you’re going to have to do more work.

  2.  It will be possible to gateway between legacy SIP devices that
      support ICE and appropriate RTP / SDP mechanisms, codecs and
      security mechanisms without using a media gateway.  A signaling
      gateway to convert between the signaling on the web side to the
      SIP signaling may be needed.

> -- Last paragraph: This is specifically about non-browser endpoints,
> right? As written, it seems to weaken the previous paragraph about
> browser endpoints, since the draft previously said the term "endpoint"
> includes both browsers and non-browsers.

Nope, it’s about all endpoints.  Look at it this way the penultimate paragraph says WebRTC browser implement the API and all WebRTC endpoints implement the protocols.  That’s in-line with the definitions defined earlier in s2.2

> -9, 2nd bullet: "Privacy concerns MUST be satisfied..."
> Is that MAY really intended as normative, or is a statement of fact? If
> normative, what actor(s) does it constrain? Also, if it is normative, the
> clause "the APIs should be available" seems to weaken the MUST. 

This is supposed to be normative.  It’s constraining the “local system” :). I’m not sure it weakens it because it’s a should not a SHOULD.  But, since this draft also addresses endpoints that don’t have to have an API, we can’t really make it a SHOULD.

> Editorial Comments:
> 
> -2.3, last paragraph: The paragraph is a single, convoluted sentence that
> is hard to parse. (It's also a comma splice). Please consider breaking
> into multiple simpler sentences.

https://github.com/rtcweb-wg/rtcweb-overview/pull/19

> -3, first paragraph: This is also convoluted and hard to parse.

https://github.com/rtcweb-wg/rtcweb-overview/pull/21

> -7, list item 1: The citiation to [3264] seems misplaced. It describes
> the offer/answer model, not SIP in general. I suggest moving the citation
> to after the word "semantics”.

https://github.com/rtcweb-wg/rtcweb-overview/pull/35/files

spt