Subject: [rtcweb] Benoit Claise's Discuss on draft-ietf-rtcweb-overview-18: (with DISCUSS)

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Apr 2017 03:32:17 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-rtcweb-overview-18: Discuss

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-overview/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

DISCUSS-DISCUSS: No action for the authors at this point in time.

Reading from the document objectives, from the abstract:

   This document gives an overview and context of a protocol suite
   intended for use with real-time applications that can be deployed in
   browsers - "real time communication on the Web".

   It intends to serve as a starting and coordination point to make
sure
   all the parts that are needed to achieve this goal are findable, and
   that the parts that belong in the Internet protocol suite are fully
   specified and on the right publication track.

Reading this, I was thinking: great, I will have the full overview.
With "deployed", "starting and coordination point to make sure that all
the parts ..." I will have some  focus on the operational aspects,
basically, how should operators operate theses browser-embedded
applications.
Now, reading further ...

   This document is intended to serve as the roadmap to the WebRTC
   specifications.  It defines terms used by other parts of the WebRTC
   protocol specifications, lists references to other specifications
   that don't need further elaboration in the WebRTC context, and gives
   pointers to other documents that form part of the WebRTC suite.

... I thought: Ok, if not covered here, at least I will have a pointer to
another operational document.
But wait:

   By reading this document and the documents it refers to, it should
be
   possible to have all information needed to implement an WebRTC
   compatible implementation.

So is this only about implementation?

I like this document very much as it explains all the RTCWEB pieces in
one location. However, there is one important piece missing: the network
management considerations. See
https://datatracker.ietf.org/doc/html/rfc5706#appendix-A
This is where I'm coming from, discussing some more with Warren (this a
cut and past from this ballot):

    [ Edit: So, after more thought (and some discussion) I think that it
would be useful for the document to at least note the fact that
technologies like this mean that some of the existing operational
practices may need to change. For example, many enterprises perform QoS
based upon the fact that certain types of devices live in certain subnets
(e.g many phones get placed in a specific VLAN using LLDP or CDP). With
more real time content coming from browsers, these matching practices
break, and so operators may not be able to QoS mark / prioritize traffic
accordingly. Perhaps something like: "One of the implications of a
solution like WebRTC is that more real-time traffic will be sourced from
computers (and not dedicated devices like telephones or videoconferencing
devices). This may have implications for operators performing QoS marking
and prioritization" ? This isn't really specific to webrtc, but rather to
a more general set of solutions like softphones and the like, but is
accelerated by WebRTC. ]

In light of the previous discussions about draft-mm-wg-effect-encrypt-11,
the operators are used to manage voice, video, gaming a certain way, with
their operational current practices. Now, their current practices might
not work any longer. What should they do now in term of monitoring,
troubleshooting, QoS, SLA monitoring, etc these days with WebRTC?
While we should add this note (or a similar one) in the doc, I'm
wondering: where are (should be) those operational aspects discussed, if
not here?
I've seen https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18, not
sure it's appropriate. Anyway, it's now in a RFC-editor state.
I could have requested a specific manageability doc in the charter. Too
late now.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 27 Apr 2017 06:57:01 -0700

Hi Benoit,

Some comments below.

On Thu, Apr 27, 2017 at 3:32 AM, Benoit Claise <[email-masked]> wrote:

> So, it seems like one thing that we could do simply here would be shifting
the title of this to something like  "Implementation and Deployment
Overview", so that is not advertising more than it provides, would that
help?

> troubleshooting, QoS, SLA monitoring, etc these days with WebRTC?

It would be really useful to be very clear about whether you are talking
about managing devices or flows.  There are two shifts here:  from
dedicated devices to browser platforms and from one set of signalling and
setup systems to another.    Is this first in scope or not?  If we are
talking about flows, it seems to me a general problem that covers
softphones, skype, and webrtc.  Does that fit your understanding of the
scope?

thanks,

Ted