jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-wish-whip

Commentary: thanxs !
Registration of new "ext" type URI (in the namespace
"urn:ietf:params:whip:ext") belonging to a WHIP Protocol Extension
MUST be reviewed by the designated expert and published in an RFC.
An RFC is REQUIRED for the registration of new value data types that
modify existing properties.  An RFC is also REQUIRED for registration
of WHEP Protocol Extensions URIs that modify WHEP Protocol Extensions
previously documented in an existing RFC.
Registration of new "ext" type URI (in the namespace
"urn:ietf:params:whip:ext") belonging to a WHIP Protocol Extension
MUST be reviewed by the designated expert and published in an RFC.
An RFC is REQUIRED for the registration of new value data types that
modify existing properties.  An RFC is also REQUIRED for registration
of WHIP Protocol Extensions URIs that modify WHIP Protocol Extensions
previously documented in an existing RFC.
Draft: draft-ietf-wish-whip

Commentary: thanxs !
The IETF has created a mailing list, "wish@ietf.org", which can be
used for public discussion of WHIP protocol extensions proposals
prior to registration.  Use of the mailing list is strongly
encouraged.  The IESG has appointed a designated expert RFC8126 who
will monitor the wish@ietf.orgg mailing list and review
registrations.
The IETF has created a mailing list, "wish@ietf.org", which can be
used for public discussion of WHIP protocol extensions proposals
prior to registration.  Use of the mailing list is strongly
encouraged.  The IESG has appointed a designated expert RFC8126 who
will monitor the wish@ietf.org mailing list and review registrations.
Draft: draft-ietf-wish-whip

Commentary: From Simulcast and scalable video coding Both  [ RFC8853 ] and Scalable Video Coding ( SVC ) , including K - SVC ( also known as " S modes " , in which multiple encodings are sent on the same SSRC ) , MAY be supported by both the Media Servers and WHIP clients through negotiation in the SDP offer / answer . [ BA ] K - SVC and “ S ” modes are different . K - SVC denotes the KEY and KEY_SHIFT modes , whereas “ S ” modes denote the encapsulation of multiple encodings within a single SSRC , as is supported in VP9 and AV1 . Diagrams of the various modes are included in the WebRTC - SVC specification : Also , SVC is not negotiated within Offer / Answer in WebRTC . It is something that the encoder can just turn on . At least for temporal modes ( L1T2 , L1T3 ) ingester support can often be taken for granted . While the VP9 and AV1 specifications require a compliant decoder to be able to decode any mode than an encoder can encode , in practice there are VP9 and AV1 hardware decoders that can not decode spatial scalability because they do not support spatial references ( e.g. a P - frame at a higher resolution than the P or I frame that it references ) . This nasty little “ wrinkle ” required us to define the “ spatialScalability ” attribute in Media Capabilities , to allow applications to discover whether a ( hardware ) decoder supports spatial scalability or not : Media Capabilities Not sure if you want to get into this in the specification . Issues are most likely to be encountered where hardware - based transcoders are used ( but in that scenario , spatial scalability probably would n’t be relevant anyway ) ,
Both Simulcast RFC8853 and Scalable Video Coding (SVC), including
K-SVC (also known as "S modes", in which multiple encodings are sent
on the same SSRC), MAY be supported by both the Media Servers and
WHIP clients through negotiation in the SDP offer/answer.
Simulcast as per RFC8853 MAY be supported by both the Media Servers
and WHIP clients through negotiation in the SDP offer/answer.
It is possible for both Media Servers and WHIP clients to support
Scalable Video Coding (SVC).  However, as there is no universal
negotiation mechanism in SDP for SVC, the encoder must consider the
negotiated codec(s), intended usage, and SVC support in available
decoders when configuring SVC.
Draft: draft-ietf-wish-whip

Commentary: Looks good . 
 thank you  ! 
 from Section 2 I do not see a definition of “ track ” . I think this is important to clarify . Section 4.2 “ While this version of the specification only supports a single audio and video track , in order to ensure forward compatibility , if the number of audio and or video tracks or number streams is not supported by the WHIP Endpoint , it MUST reject the HTTP POST request with a " 406 Not Acceptable " error response . ” 
 updated the PR to add MediaStream / MediaStreamTrack references
Once the ICE/DTLS session is set up, the media will flow
unidirectionally from the encoder/media producer (WHIP client) to the
broadcasting ingestion endpoint (Media Server).  In order to reduce
complexity, no SDP renegotiation is supported, so no tracks or
streams can be added or removed once the initial SDP offer/answer
over HTTP is completed.
Once the ICE/DTLS session is set up, the media will flow
unidirectionally from the encoder/media producer (WHIP client) to the
broadcasting ingestion endpoint (Media Server).  In order to reduce
complexity, no SDP renegotiation is supported, so no "m=" sections
can be added once the initial SDP offer/answer over HTTP is
completed.
While this version of the specification only supports, at most, a
single audio and video track in a single media stream. (therefore,
all "m=" sections MUST contain an "msid" attribute with the same
value as per ), in order to ensure forward compatibility,
if the number of audio and or video tracks or number streams is not
supported by the WHIP Endpoint, it MUST reject the HTTP POST request
with a "406 Not Acceptable" error response.
This version of the specification only supports, at most, a single
audio and video MediaStreamTrack in a single MediaStream as defined
in  and therefore, all "m=" sections MUST contain an
"msid" attribute with the same value.  However, it would be possible
for future revisions of this spec to allow more than a single
MediaStream or MediaStreamTrack of each media kind, so in order to
ensure forward compatibility, if the number of audio and or video
tracks or number streams is not supported by the WHIP Endpoint, it
MUST reject the HTTP POST request with a "406 Not Acceptable" error
response.
Draft: draft-ietf-wish-whip

Commentary: ping ? 
 “ The response may optionally contain the new set of ICE candidates for the Media Server and the new entity - tag correspond to the new ICE session in an ETag response header field . ” Is this really meant to indicate that the new ICE candidates AND the new entity - tag are optional ? I would have expected that after an ICE restart a new entity - tag is required . 
 The optionally only applies to the first part of , will reword it .
If the HTTP PATCH request results in an ICE restart, the WHIP
resource SHALL return a "200 OK" with an "application/trickle-ice-
sdpfrag" body containing the new ICE username fragment and password.
The response may optionally contain the new set of ICE candidates for
the Media Server and the new entity-tag correspond to the new ICE
session in an ETag response header field.
If the HTTP PATCH request results in an ICE restart, the WHIP
resource SHALL return a "200 OK" with an "application/trickle-ice-
sdpfrag" body containing the new ICE username fragment and password.
Also, the "200 OK" response for a sucesscull ICE restart MUST contain
the new entity-tag corresponding to the new ICE session in an ETag
response header field and MAY contain a new set of ICE candidates for
the Media Server.
Draft: draft-ietf-wish-whip

Commentary: ping ? 
 Section 4.1 “ The WHIP client MAY perform trickle ICE or ICE restarts ] by sending an HTTP PATCH request … ” Why is there a reference to RFC8863 , which specifies ICE PAC , here ? In general a reference to ICE PAC is useful , because this draft allows an offer without any candidates . So maybe that reference should go at the end of : “ The initial offer by the WHIP client MAY be sent after the full ICE gathering is complete with the full list of ICE candidates , or it MAY only contain local candidates ( or even an empty list of candidates ) . ” 
 I think it was a typo . 
 I created a PR to fix the tricke ice reference and add the pac one as suggested .
The initial offer by the WHIP client MAY be sent after the full ICE
gathering is complete with the full list of ICE candidates, or it MAY
only contain local candidates (or even an empty list of candidates).
The initial offer by the WHIP client MAY be sent after the full ICE
gathering is complete with the full list of ICE candidates, or it MAY
only contain local candidates (or even an empty list of candidates)
as per RFC8863.
The WHIP client MAY perform trickle ICE or ICE restarts RFC8863 by
sending an HTTP PATCH request to the WHIP resource URL with a body
containing a SDP fragment with MIME type "application/trickle-ice-
sdpfrag" as specified in RFC8840.  When used for trickle ICE, the
body of this PATCH message will contain the new ICE candidate; when
used for ICE restarts, it will contain a new ICE ufrag/pwd pair.
The WHIP client MAY perform trickle ICE or ICE restarts as per
RFC8838 by sending an HTTP PATCH request to the WHIP resource URL
with a body containing a SDP fragment with MIME type "application/
trickle-ice-sdpfrag" as specified in RFC8840.  When used for trickle
ICE, the body of this PATCH message will contain the new ICE
candidate; when used for ICE restarts, it will contain a new ICE
ufrag/pwd pair.
Draft: draft-ietf-wish-whip

Commentary: could you take a look please ? 
 The current text ignores the issue that ( in the absence of OPTIONS ) the offer must be sent before it is set as the local description , in order to avoid starting the ICE agent prematurely . I think we should consult an ICE specialist in order to understand what consequences that will have on connectivity . 
 There is already a note already covering that case . It is up to the WHIP client implementation to know which is its ICE implementation support regarding this case and choose to call setLocalDescription or not before updateConfiguration . The only case were a WHIP client is not tightly coupled with a ICE implementation is on browsers , and we already have checked that it works on all webrtc browsers .
There are some WebRTC implementations that do not support updating
the STUN/TURN server configuration after the local offer has been
created as specified in RFC8829 section 4.1.18.  In order to support
these clients, the WHIP endpoint MAY also include the STUN/TURN
server configuration on the responses to OPTIONS request sent to the
WHIP endpoint URL before the POST request is sent.
There are some WebRTC implementations that do not support updating
the STUN/TURN server configuration after the local offer has been
created as specified in RFC8829 section 4.1.18.  In order to support
these clients, the WHIP endpoint MAY also include the STUN/TURN
server configuration on the responses to OPTIONS request sent to the
WHIP endpoint URL before the POST request is sent.  However, this
method is not NOT RECOMMENDED and if supported by the underlying WHIP
Client's webrtc implementation, the WHIP Client SHOULD wait for the
information to be returned by the WHIP Endpoint on the response of
the HTTP POST request instead.
Draft: draft-ietf-wish-whip

Commentary: As per discussion during IETF WISH meeting 
 thank you for the PR Adam ! One further question , I think we should consistently use the return code and reason phrase styling across the document . what would be best ? 200 OK 200 " OK " 200 ( OK )
Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource.
If both Trickle ICE or ICE restarts are not supported by the WHIP
resource, it MUST return a 405 Method Not Allowed response for any
HTTP PATCH request.  If the WHIP resource supports either Trickle ICE
or ICE restarts, but not both, it MUST return a 501 Not Implemented
for the HTTP PATCH requests that are not supported.
Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource.
If the WHIP resource supports either Trickle ICE or ICE restarts, but
not both, it MUST return a 405 (Not Implemented) for the HTTP PATCH
requests that are not supported.  If the server does not support the
PATCH method for any purpose, it returns a 501 (Not Implemented), as
described in RFC7231 section 6.6.2.
Draft: draft-ietf-wish-whip

Commentary: Consider a client that does Since the ICE gathering process has started at the time of , it is too late at this point to call . Thus , a way is needed to find the set of ICE servers before the offer is POSTed to the server . In his mail of 12 July 2022 , Sergio suggests a different procedure : This alternate procedure should work , but it is somewhat unusual ; thus , the spec should describe this procedure in detail , and indicate that this is the procedure that the WHIP client must use if it wishes to use the server - provided ICE servers . What is more , with this procedure the posted offer does not contain any local candidates , which might imply that client - side Trickle ICE is a requirement , at least in some environments . Again , this should be discussed in the draft . 
 That is not true . If server is on a public IP address or behind a port forwarding NAT . The candidates sent by the server are enough to establish the ICE connection . Gathering all the ICE candidates on the local offer are only required if the client does not support trickle and the server is behind of a NAT that requires hole punching . I do n't think we should explain how to use webrtc apis in the spec . 
 So WHIP is restricted to the case where the server is on a public IP , with no firewall ? That would be fine with me , but if that 's the case then IMHO it needs to be stated explicitly in the draft . What happens if the client is on a restrictive network that only lets outgoing TCP through , which is unfortunately still the case in many university networks ? Are you assuming that the server supports passive TCP ICE ? If so , should that be mentioned in the draft somewhere ? 
 The turn server configuration via OPTIONS is not going to be removed . I can add a note like :
NOTE: Depending on the ICE Agent implementation, the WHIP client may
need to call the setConfiguration method before calling the
setLocalDespcription method with the local SDP offer in order to
avoid having to perform an ICE restart for applying the updated STUN/
TURN server configuration on the next ICE gathering phase.
Draft: draft-ietf-wish-whip

Commentary: Until now , I 've been working under the assumption that WHIP is limited to two tracks ( audio+video ) belonging to a single stream . However , I 'm now realising that there 's nothing in the draft that says this is the case . Please clarify which of the following is correct : client MUST offer at most one audio and one video track ( possibly simulcast / SVC ) belonging to a single stream ; the server MUST return an error if there are more than two tracks ; client MAY offer more than two tracks ; how to handle this case is out of scope for WHIP , but the server MAY return an error if there are more than two tracks and the client MUST retry with just two tracks ; client MAY offer multiple tracks in multiple streams , and the server MUST accept the multiple streams . My preference is for ( 1 ) or ( 2 ) , but I can live with ( 3 ) . 
 I had doubts regarding this , as I foresee that we will want to support multi tracks / streams in the near future ( for multilanguage support for example ) I would propose something like . I do n't want to add the retry client logic to the client , as I think most of the times it would be better to inform the end user about the error and explicitly asking form confirmation before doing any change in the stream / track . Note that this could happen today if the server supports audio only and the whip client is sending audio and video . I think that it is better to fail than just force retrying automatically with audio only .
While this version of the specification only supports a single audio
and video track, in order to ensure forward compatibility, if the
number of audio and or video tracks or number streams is not
supported by the WHIP Endpoint, it MUST reject the HTTP POST request
with a 406 Not Acceptable error code.
Furthermore, the WHIP Endpoint SHOULD NOT reject individual "m="
sections as per RFC8829 section 5.3.1 in case there is any error
processing the "m=" section, but reject the HTTP POST request with a
406 Not Acceptable error code to prevent having partially successful
WHIP sessions.
Draft: draft-ietf-wish-whip

Commentary: fix for 
 Unsure if trickle ICE is mandatory for webrtc or not , but it is optional for the APP point of view : as per rfc8829 , 3.5.2 . ICE Candidate Trickling : However I think it would not harm to point it out in Section 4.2 
 PR available here : 
 Is it legal for a server to support Trickle ICE but not ICE Restarts ? If that 's the case , then the use of 405 is somewhat misleading , since the PATCH method is allowed , just not for ICE Restarts . 
 I think you are correct , if patch request is not supported the server must return a 405 response , if only ice restarts are not supported it should return a 501 Not Implemented . 
 Does WebRTC mandate support of ICE restart and trickle ICE ? If so , should the WHIP optional support be mentioned in Section 4.2 ( WebRTC Constraints ) ?
Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource.
If Trickle ICE or ICE restarts are not supported by the WHIP
resource, it MUST return a 405 Method Not Allowed response for any
HTTP PATCH request.
Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource.
If both Trickle ICE or ICE restarts are not supported by the WHIP
resource, it MUST return a 405 Method Not Allowed response for any
HTTP PATCH request.  If the WHIP resource supports either Trickle ICE
or ICE restarts, but not both, it MUST return a 501 Not Implemented
for the HTTP PATCH requests that are not supported.
Draft: draft-ietf-wish-whip

Commentary: So it 's a MUST or a SHOULD ? 
 wdyt ? is it ok to merge it and will it solve your concerns ? 
 I 'm sorry , but I still do n't know what that says . Does it say that the client MUST NOT use If - Match on the DELETE , or does it say that the server MUST ignore an If - Match on the DELETE ? I suggest making it clear to whom the requirement applies . 
 should be applicable only to clients , is it better now ? 
 ping ? 
 I think this is still ambiguous due to the MUST in the first part . I suggest removing the first part : 
 what about now ? 
 ping ? 
 merging this , we can modify it after the WGLC 
 Yeah , it 's okay now .
A WHIP client sending a PATCH request for performing trickle ICE MUST
contain an If-Match header with the latest known entity-tag as per
RFC7232 section 3.1.  When the PATCH request is received by the WHIP
resource, it MUST compare the entity-tag value requested with the
current entinty-tag of the resource as per RFC7232 section 3.1 and
return a 412 Precondition Failed response if they do not match.
Entity-tag validation MUST only be used for HTTP requests requiring
to match a known ICE session and SHOULD NOT be used otherwise, for
example in the HTTP DELETE request to terminate the session.
A WHIP client sending a PATCH request for performing trickle ICE MUST
contain an If-Match header with the latest known entity-tag as per
RFC7232 section 3.1.  When the PATCH request is received by the WHIP
resource, it MUST compare the entity-tag value requested with the
current entity-tag of the resource as per RFC7232 section 3.1 and
return a 412 Precondition Failed response if they do not match.
WHIP clients SHOULD NOT use entity-tag validation when matching a
specific ICE session is not required, such as for example when
initiating a DELETE request in order to terminate a session.
Draft: draft-ietf-wish-whip

Commentary: While this is not ambiguous , it might be read as " MAY NOT " . I suggest rewording as " Support for trickle ICE by WHIP resources is OPTIONAL " . 
 wdyt ? is it ok to merge it and will this solve your concerns ? 
 Yes , that 's much better .
The WHIP client MAY perform trickle ICE or an ICE restarts RFC8863 by
sending a HTTP PATCH request to the WHIP resource URL with a body
containing a SDP fragment with MIME type "application/trickle-ice-
sdpfrag" as specified in RFC8840 with the new ICE candidate or ICE
ufrag/pwd for ICE restarts.  A WHIP resource MAY not support trickle
ICE (i.e.  ICE lite media servers) or ICE restart, in that case, it
MUST return a 405 Method Not Allowed response for any HTTP PATCH
request.
The WHIP client MAY perform trickle ICE or an ICE restarts RFC8863 by
sending a HTTP PATCH request to the WHIP resource URL with a body
containing a SDP fragment with MIME type "application/trickle-ice-
sdpfrag" as specified in RFC8840 with the new ICE candidate or ICE
ufrag/pwd for ICE restarts.
Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource.
If Trickle ICE or ICE restarts are not supported by the WHIP
resource, it MUST return a 405 Method Not Allowed response for any
HTTP PATCH request.
Draft: draft-ietf-wish-whip

Commentary: I 'd like to propose removing the mention of a specific company / brand in the abstract as well as some clarification around the language used to describe the protocol and why it is important / different from " other protocols " .
While WebRTC has been very successful in a wide range of scenarios,
its adoption in the broadcasting/streaming industry is lagging
behind.  Currently there is no standard protocol (like SIP or RTSP)
designed for ingesting media in a streaming service, and content
providers still rely heavily on protocols like RTMP for it.
These protocols are much older than webrtc and lack by default some
important security and resilience features provided by webrtc with
minimal delay.
The media codecs used in older protocols do not always match those
being used in WebRTC, mandating transcoding on the ingest node,
introducing delay and degrading media quality.  This transcoding step
is always present in traditional streaming to support e.g.  ABR, and
comes at no cost.  However webrtc implements client-side ABR, also
called Network-Aware Encoding by e.g.  Huavision, by means of
simulcast and SVC codecs, which otherwise alleviate the need for
server-side transcoding.  Content protection and Privacy Enhancement
can be achieved with End-to-End Encryption, which preclude any
server-side media processing.
This document proposes a simple HTTP based protocol that will allow
WebRTC endpoints to ingest content into streaming services and/or
CDNs to fill this gap and facilitate deployment.
While WebRTC has been very sucessful in a wide range of scenarios,
its adoption in the broadcasting/streaming industry is lagging
behind.  Currently there is no standard protocol (like SIP or RTSP)
designed for ingesting media into a streaming service using WebRTC
and so content providers still rely heavily on protocols like RTMP
for it.
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
(wich 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 simulcasting 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 end-to-end
transport of media is implicit.
This document proposes a simple HTTP based protocol that will allow
WebRTC based ingest of content into streaming servics and/or CDNs.