Original text:
4.4. <del> The WHIP endpoint MAY return ICE server configuration URLs and </del>  credentials usable by the client in the "201 Created" response to the HTTP POST request to the WHIP endpoint URL. <del> Each ICE server will be returned using the "Link" header field RFC8288 with a "rel" attribute value of "ice-server".  The Link target URI will contain the ICE server URL.  The credentials are encoded in the Link target attributes as follows: </del>  username: If the Link header field represents a TURN server, and credential-type is "password", then this attribute specifies the value should be used when that TURN server requests authorization. The default value if the attribute is not present is "password".  There are some WebRTC implementations that do not support updating <del> the ICE server configuration after the local offer has been created. In order to support these clients, the WHIP endpoint MAY also include the ICE server configuration on the responses to an authenticated OPTIONS request sent to the WHIP endpoint URL sent before the POST requests. </del>  It might be also possible to configure the STUN/TURN server URLs with long term credentials provided by either the broadcasting service or 4.5.  WHIP endpoints and resources MAY require the HTTP request to be authenticated using an HTTP Authorization header field with a Bearer token as specified in RFC6750 section 2.1.  WHIP clients MUST not configured to use a bearer token, the HTTP Authorization header field must not be sent in any request. <del> 4.6. </del>  Both Simulcast RFC8853 and Salable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent simulcast offer MUST create an answer according to the procedures RFC8853 section 5.3.2. <del> 4.7. </del>  In order to support future extensions to be defined for the WHIP protocol, a common procedure for registering and announcing the new In this theoretical case, the HTTP 201 response to the HTTP POST request would look like: <del> 5. </del>  HTTPS SHALL be used in order to preserve the WebRTC security model. <del> 6. </del>  The link relation type below has been registered by IANA per Section 4.2 of RFC8288. <del> 6.1. </del>  Relation Name: ice-server Reference: TBD <del> 7. </del> 

Reviewer comments:
NAME wdyt?
he usability of the ICE server configuration seem to go far beyond WHIP. Also, in my opinion the way you configure your STUN/TURN servers is slightly outside the scope of core WHIP. But, assuming you want to keep the text: First, you should add references to where the STUN- and TURN server URIs are defined. Second, I believe Link URIs have to be enclosed by . Third, I think the "ice-server" value is misleading. An ICE server is not the same thing as a STUN/TURN server. You don't even have to use ICE in order to support STUN/TURN. Fourth, related to the third issue, perhaps you should use the "urn:ietf:params:whip:" appendix also for the STUN/TURN servers? Fifth, you say that not all webrtc implementations may allow STUN/TURN server re-configuring after the offer has been created. But, does WebRTC even define a mechanism to programmatically configure the servers? If so, please add a reference. If not, please indicate that.
Using WHIP without a valid TURN/STUN server configuration will fail in many cases, so In practice any WHIP service provider will also be providing STUN/TURN services to be used with. WHIP allows sending the STUN/TURN server configuration in the HTTP request in order to not have to manualy configure the configuration manually o the client. Moreover, some WHIP providers may want to restrict the usage of their TURN/STUN server and only provide short lived credentials that are only valid in the context of the WHIP session. The term is taken from the W3C webrtc spec that uses the configuration property when creating the PC. Regarding the and , yes, it is a typo and should be corrected. Regarding the it was originally propossed like that but i was agreed that this could be used to configure other webrtc services and not only WHIP and it could be better to not have the urn be whip-specific WebRTC w3c spec supports reconfiguration of the stun/turn server connection via URL
Won't the WHIP servers have a publicly available IP address in most cases? And, as the WHIP client is the one always establishing the media path, there should be no need for a STUN/TURN server in such cases. Or? Ok. I suggest adding a note to indicate that. I suggest adding some text and point that out. Thanks! I suggest adding a reference,
Clients may be behind restricted firewalls which block UDP. It is easier to just deploy a TURN server to do TURN over TCP/TLS than implement ICE TCP on the media server (and ICE TLS is not standard anyway). Also, you typically have less TURN servers than media servers, so it is easier to have them allowed by IP on the firewalls. In our case for example, our IPs of the media server pool are dinamic, so we must use TURN server IPs instead. I will add notes for the other comments as suggested

Revised text:
4.4.  <ins> The WHIP endpoint MAY return STUN/TURN server configuration URLs and </ins> credentials usable by the client in the "201 Created" response to the HTTP POST request to the WHIP endpoint URL.  <ins> Each STUN/TURN server will be returned using the "Link" header field RFC8288 with a "rel"" attribute value of "ice-server".  The Link target URI is the server URL as defined in RFC7064 and RFC7065.  The credentials are encoded in the Link target attributes as follows: </ins> username: If the Link header field represents a TURN server, and credential-type is "password", then this attribute specifies the value should be used when that TURN server requests authorization. The default value if the attribute is not present is "password". <ins> NOTE: The naming of both the "rel" attribute value of "ice-server" and the target attributes follows the one used on the W3C WebRTC recomendation ?W3C.REC-webrtc-20210126 RTCConfiguration dictionary in section 4.2.1. "rel" attribute value of "ice-server" is not prepended with the "urn:ietf:params:whip:" so it can be reused by other specifications which may use this mechanishm to configure the usage of STUN/TURN servers. </ins> There are some WebRTC implementations that do not support updating  <ins> 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. The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTION request processing and increase the processing required to handle that request.  In order to prevent this, the WHIP Endpoint SHOULD NOT return the STUN/TURN server configuration if the OPTION request is a preflight request for CORS, that is, if The OPTION request does not contain an Access-Control-Request-Method with "POST" value and the the Access-Control-Request-Headers HTTP header does not contain the "Link" value. </ins> It might be also possible to configure the STUN/TURN server URLs with long term credentials provided by either the broadcasting service or 4.5. <ins> 5. </ins> WHIP endpoints and resources MAY require the HTTP request to be authenticated using an HTTP Authorization header field with a Bearer token as specified in RFC6750 section 2.1.  WHIP clients MUST not configured to use a bearer token, the HTTP Authorization header field must not be sent in any request.  <ins> 5.1. </ins> Both Simulcast RFC8853 and Salable Video Coding (SVC), including K-SVC (also known as "S modes", in which multiple encodings are sent simulcast offer MUST create an answer according to the procedures RFC8853 section 5.3.2.  <ins> 5.2. </ins> In order to support future extensions to be defined for the WHIP protocol, a common procedure for registering and announcing the new In this theoretical case, the HTTP 201 response to the HTTP POST request would look like:  <ins> 6. </ins> HTTPS SHALL be used in order to preserve the WebRTC security model.  <ins> 7. </ins> The link relation type below has been registered by IANA per Section 4.2 of RFC8288.  <ins> 7.1. </ins> Relation Name: ice-server Reference: TBD  <ins> 8. </ins>