Process for "feature at risk" designation

At the virtual interim on May 2, we had a good discussion of the considerations that should go into designating a “feature at risk”.

Some things that came up during that conversation:

  *   A process that requires a quick response to a proposed PR may not work well because people may not be paying enough attention.
  *   Just because a feature is not currently in plan doesn’t mean it there is “no commitment” to ever implementing it.
  *   Removing a feature that is part of the WebRTC requirements prior to PR does not make sense, since meeting the requirements is a pre-requisite for going to CR.

Given that the process we have been using so far does not appear to make sense, the question arises as to what we should be doing instead, and also, how to determine whether those features designated “at risk” should remain so.

On the first point, it seems to me that we need to have a process more formal than just proposing a PR and commenting on it.  For example, this might involve:

  1.  Enumerating the features currently designated “at risk”.
  2.  Considering which ones are part of the requirements in IETF documents (perhaps as part of the “requirements review” that is ongoing)
  3.  Asking for feedback not just on short-term implementation plans, but on longer-term needs.
  4.  Considering whether the feature is needed at all, or if needed whether implementation should be made optional.

Does this make sense?

For reference, as of today, the following features are marked “at risk” (see: https://rawgit.com/w3c/webrtc-pc/master/webrtc.html):

Feature at Risk 1:  Welcome to “features at risk” in WebRTC-PC. The first rule of “features at risk” in WebRTC-PC is that you DO NOT talk about feature at risk 1.  The second rule of “features at risk” in WebRTC is that you DO NOT talk about feature at risk 1. Sorry for quoting from the movie “Fight Club”. You cannot talk about feature at risk 1 because there is no feature at risk 1 (the numbering starts at 2).  Perhaps we should fix this 😉

Feature at Risk 2: non-multiplexed RTP/RTCP (negotiate and support for rtcpTransport)

Feature at Risk 3: RTCCertificate.getAlgorithm()
     Note: During the interim, EKR expressed surprise as to why this was “at risk”.   Since there have been changes to the certificates returned by getConfiguration().certificates (e.g. the pre-configured certificates are no longer returned), perhaps we should be having a discussion about whether getAlgorithm() is still needed.  Since it is no longer possible to use getAlgorithm() to determine the algorithm used in a pre-configured certificate, the only use left is to return the algorithm used to create a certificate created by the application, which it could have stored for later retrieval.

Feature at Risk 4: Identity