Draft: draft-ietf-wish-whip

Commentary: The text says : " The media codecs used in older protocols do not always match those being used in WebRTC , mandating transcoding on the ingest node , " I do n't understand this sentence . If I use an " older protocol " , e.g , RTMP , why do I need to care about WebRTC codecs ? 
 That refers if you use RTMP for ingest and WebRTC for viewing . 
 rewriten the editorial in 
 The text says : " These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with minimal delay . " I assume you refer to RTMP , which is mentioned in the previous Section . Does n't RTMPS solve some of the security issues ? But in general , if you want to put up WHIP against RTMP , I think you need a little more text . Also , as WHIP is supposed to be an " easy to implement " protocol , I think it would be fair to also list some of the functions NOT supported compared to e.g. , RTMP . As I have mentioned before , there is no command for start the ingestion - it is assumed to have begun when the connection has been established . Also , there is no PAUSE / RESUME . 
 It is more referring to RTSP which lacks DTLS support . no command for start the ingestion - it is assumed to have begun when the connection has been established . Also , there is no PAUSE / RESUME . RTMP protocol was intended as an RPC mechanism between the flash player and server . It allowed to create custom apps both on client and server side , which supported a wide range of methods using AMF . However , current " RTMP protocol " implemented for ingesting is a reversed engineered version of the implementation done by the FMS and it lacks support for PAUSE / RESUME and the publication is started from the start of the RTMP connection ( same as whip ) . 
 rewriten the editorial in
Currently, there is no standard protocol designed for ingesting media
into a streaming service using WebRTC and so content providers still
rely heavily on protocols like RTMP for doing so.
These protocols are much older than WebRTC and by default lack some
important security and resilience features provided by WebRTC with
minimal overhead and additional latency.
The media codecs used for ingestion in older protocols tend to be
limited and not negotiated.  WebRTC includes support for negotiation
of codecs, potentially alleviating transcoding on the ingest node
(which can introduce delay and degrade media quality).  Server side
transcoding that has traditionally been done to present multiple
renditions in Adaptive Bit Rate Streaming (ABR) implementations can
be replaced with Simulcast RFC8853 and SVC codecs that are well
supported by WebRTC clients.  In addition, WebRTC clients can adjust
client-side encoding parameters based on RTCP feedback to maximize
encoding quality.
Encryption is mandatory in WebRTC, therefore secure transport of
media is implicit.
So, currently, there is no standard protocol designed for ingesting
media into a streaming service using WebRTC and so content providers
still rely heavily on protocols like RTMP for doing so.  Most of
those protocols are not RTP based, requiring media protocol
translation when doing egress via WebRTC.  Avoiding this media
protocol translation is desirable as there is no functional parity
between those protocols and WebRTC and it increases the
implementation complexity at the media server side.
Also, the media codecs used in those protocols tend to be limited and
not negotiated, not always matching the mediac codes supported in
WebRTC.  This requires to perform transcoding on the ingest node,
which introduces delay, degrades media quality and increases the
processing workload required on the server side.  Server side
transcoding that has traditionally been done to present multiple
renditions in Adaptive Bit Rate Streaming (ABR) implementations can
be replaced with Simulcast RFC8853 and SVC codecs that are well
supported by WebRTC clients.  In addition, WebRTC clients can adjust
client-side encoding parameters based on RTCP feedback to maximize
encoding quality.