Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti-rtcweb-rfc8829bis-05> for your review

[Sean Turner <[e-mail]>]

Checking in to make sure everybody has seen these.

spt

> On Oct 10, 2023, at 17:32, [e-mail] wrote:
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] Section 3.4.1:  Would you like to expand "MID" as
> "Media Identification" per RFC 9143?  (We ask this question, and a
> few similar questions later on, because this bis document provides an
> opportunity to make minor editorial improvements.)
> 
> Original:
> However, in
> certain cases where an "m=" section has been rejected, as discussed
> in Section 5.2.2 below, that "m=" section will be "recycled" and
> associated with a new RtpTransceiver with a new MID value.
> 
> Suggested:
> However, in
> certain cases where an "m=" section has been rejected, as discussed
> in Section 5.2.2 below, that "m=" section will be "recycled" and
> associated with a new RtpTransceiver with a new Media Identification
> (MID) value. -->
> 
> 
> 2) <!-- [rfced] Section 3.5.2.1:  We do not see "non-JSEP endpoint" or
> "non-JSEP" mentioned in Section 5.10.  Please confirm that this
> citation is correct and will be clear to readers.
> 
> Original:
> The MID is a "media stream identification" value, as defined in
> [RFC5888], Section 4, which provides a more robust way to identify
> the "m=" section in the session description, using the MID of the
> associated RtpTransceiver object (which may have been locally
> generated by the answerer when interacting with a non-JSEP endpoint
> that does not support the MID attribute, as discussed in Section 5.10
> below). -->
> 
> 
> 3) <!-- [rfced] Section 3.5.5:  As RFC 8829 was published two years ago,
> please confirm that the following text is still applicable today.
> 
> Original:
> While this specification formally relies on [RFC8445], at the time of
> its publication, the majority of WebRTC implementations support the
> version of ICE described in [RFC5245]. -->
> 
> 
> 4) <!-- [rfced] Section 4.1.1:  We see that a few paragraphs earlier in
> this section "preferred policy regarding use of" as written in
> RFC 8829 was changed to "preferred policy regarding the use of".
> Because that sentence and the one listed here are close together, the
> change in one place but not the other seemed to stand out a bit.
> We updated as noted below.  Please let us know any concerns.
> 
> Original:
> The application can specify its preferred policy regarding use of
> RTP/RTCP multiplexing [RFC5761] using one of the following policies:
> 
> Currently:
> The application can specify its preferred policy regarding the use
> of RTP/RTCP multiplexing [RFC5761] using one of the following
> policies: -->
> 
> 
> 5) <!-- [rfced] Sections 4.1.8 and 4.1.9:  We see two instances of
> "specification that defines the given SDP line" and one instance of
> "RFC that specifies the given SDP line".  Would you like these to be
> made to match (i.e., either the more general "specification" or the
> more specific "RFC")?
> 
> (We assume that, in the case of the second sentence, RFCs are the
> only type of specification that will define a given SDP line.)
> 
> Original:
> In the initial offer, the generated SDP will contain all desired
> functionality for the session (functionality that is supported but
> not desired by default may be omitted); for each SDP line, the
> generation of the SDP will follow the process defined for generating
> an initial offer from the specification that defines the given SDP
> line.
> ...
> For each
> existing stream, the generation of each SDP line MUST follow the
> process defined for generating an updated offer from the RFC that
> specifies the given SDP line.
> ...
> As an answer, the generated SDP will contain a specific configuration
> that specifies how the media plane should be established; for each
> SDP line, the generation of the SDP MUST follow the process defined
> for generating an answer from the specification that defines the
> given SDP line. -->
> 
> 
> 6) <!-- [rfced] Sections 5.2.1 and 5.3.1:  Please confirm that
> "Sections 4 and 5" means "Sections 4 and 5 of this document" and not
> "Sections 4 and 5 of [RFC8854]".
> 
> Original:
> The FEC mechanisms that MUST be supported are
> specified in [RFC8854], Section 7, and specific usage for each
> media type is outlined in Sections 4 and 5.
> ...
> The FEC mechanisms that
> MUST be supported are specified in [RFC8854], Section 7, and
> specific usage for each media type is outlined in Sections 4 and
> 5. -->
> 
> 
> 7) <!-- [rfced] Section 5.2.1:  RFC 8841 does not have a Section 4.2.2.
> As Section 4.4.2 of RFC 8841 contains the indicated information, we
> changed "4.2.2" to "4.4.2".  Please let us know if this is incorrect.
> 
> Original:
> The
> <fmt> value MUST be set to "webrtc-datachannel" as specified in
> [RFC8841], Section 4.2.2.
> 
> Currently:
> The
> <fmt> value MUST be set to "webrtc-datachannel" as specified in
> [RFC8841], Section 4.4.2. -->
> 
> 
> 8) <!-- [rfced] Section 5.2.3.1:  We do not see any mention of ufrag or
> pwd attributes in Section 4.4.3.1.1 of RFC 8839.  Please confirm that
> this citation (as opposed to, say, Section 4.4.1.1.1 of RFC 8839) is
> correct and will be clear to readers.
> 
> Original:
> If the IceRestart option is specified, with a value of "true", the
> offer MUST indicate an ICE restart by generating new ICE ufrag and
> pwd attributes, as specified in [RFC8839], Section 4.4.3.1.1. -->
> 
> 
> 9) <!-- [rfced] Section 5.2.3.2:  Because of "For codecs that have their
> own ..." in these sentences, we changed "that codec" to "those
> codecs".  Please let us know if this is incorrect (e.g., perhaps
> "such codecs" or "a given codec" was intended?).
> 
> Original:
> For codecs that have their own internal silence suppression
> support, the appropriate fmtp parameters for that codec MUST be
> specified to indicate that silence suppression for received audio is
> desired.
> ...
> For
> codecs that have their own internal silence suppression support, the
> appropriate fmtp parameters for that codec MUST be specified to
> indicate that silence suppression for received audio is not desired.
> 
> Currently:
> For codecs that have their own internal silence suppression
> support, the appropriate fmtp parameters for those codecs MUST be
> specified to indicate that silence suppression for received audio is
> desired.
> ...
> For
> codecs that have their own internal silence suppression support, the
> appropriate fmtp parameters for those codecs MUST be specified to
> indicate that silence suppression for received audio is not desired. -->
> 
> 
> 10) <!-- [rfced] Section 5.3.1:  Should 'semantics of "BUNDLE"' be
> 'semantics "BUNDLE"' per the next sentence and Section 5.2.1?
> 
> Original (the next sentence is included for context):
> If "a=group" attributes with semantics of "BUNDLE" are offered,
> corresponding session-level "a=group" attributes MUST be added as
> specified in [RFC5888].  These attributes MUST have semantics
> "BUNDLE" and MUST include all mid identifiers from the offered bundle
> groups that have not been rejected. -->
> 
> 
> 11) <!-- [rfced] Section 5.3.3:  We only see one subsection and one
> option in Section 5.3.3 (as compared to the two subsections and
> two options provided in Section 5.2.3).  Please confirm that "options
> are" is correct and will be clear to readers.
> 
> Original:
> The following options are supported in RTCAnswerOptions.
> 
> Perhaps:
> The following option is supported in RTCAnswerOptions. -->
> 
> 
> 12) <!-- [rfced] Section 5.8.1: Should "mids" be "MIDs" or perhaps "MID
> value" as used elsewhere in this document?
> 
> Original:
> *  Any "a=group" lines are parsed as specified in [RFC5888],
>    Section 5, and the group's semantics and mids are stored. -->
> 
> 
> 13) <!-- [rfced] Section 5.10:  We see that "local implementation" in
> version -04 of this document was changed to "local application"
> in several places in version -05.  Please confirm that this
> remaining instance of "local implementation" is correct.
> 
> Original:
> -  For each specified fmtp parameter that is supported by the
>    local implementation, enable them on the associated media
>    formats. -->
> 
> 
> 14) <!-- [rfced] Section 5.10:  The initial-capitalized "Maximum" reads
> oddly here, as it doesn't seem to be part of the abbreviation
> (although we see the same definition in RFCs 3890 and 8859, as
> opposed to RFC 6364).  Could we rephrase as follows?
> 
> Original:
> -  For any specified "TIAS" ("Transport Independent Application
>    Specific Maximum") bandwidth value, set this value as a
>    constraint on the maximum RTP bitrate to be used when sending
>    media, as specified in [RFC3890].
> 
> Possibly:
> -  For any specified "TIAS" ("Transport Independent Application
>    Specific (maximum)") bandwidth value, set this value as a
>    constraint on the maximum RTP bitrate to be used when sending
>    media, as specified in [RFC3890]. -->
> 
> 
> 15) <!--[rfced] Section 5.11: Please review that "[RFC8839], Section 4.4.3.1" is 
> the correct section here, relevant to "discard any associated ICE components". 
> 
> Original:
>   *  If the "m=" section has been rejected (i.e., the <port> value is
>      set to zero in the answer), stop any reception or transmission of
>      media for this section, and, unless a non-rejected "m=" section is
>      bundled with this "m=" section, discard any associated ICE
>      components, as described in [RFC8839], Section 4.4.3.1.
> -->
> 
> 
> 16) <!-- [rfced] Section 7.2:  We found 3 unquoted instances of "a=..."
> parameters in running text.  As all other such entries appear to be
> quoted, we quoted these as well.  Please let us know any objections.
> 
> Side question:  Should 'setup:passive' be '"a=setup:passive"'?
> 
> Original:
> In addition to the new "m="
> sections for video, both of which are offering FEC and one of which
> is offering simulcast, note the increment of the version number in
> the "o=" line; changes to the "c=" line, indicating the local
> candidate that was selected; and the inclusion of gathered candidates
> as a=candidate lines.
> ...
> In addition to the
> acceptance of the video "m=" sections, the use of a=recvonly to
> indicate one-way video, and the use of a=imageattr to limit the
> received resolution, note the use of setup:passive to maintain the
> existing DTLS roles.
> 
> Currently:
> In addition to the new "m="
> sections for video, both of which are offering FEC and one of which
> is offering simulcast, note the increment of the version number in
> the "o=" line; changes to the "c=" line, indicating the local
> candidate that was selected; and the inclusion of gathered candidates
> as "a=candidate" lines.
> ...
> In addition to the
> acceptance of the video "m=" sections, the use of "a=recvonly" to
> indicate one-way video, and the use of "a=imageattr" to limit the
> received resolution, note the use of setup:passive to maintain the
> existing DTLS roles. -->
> 
> 
> 17) <!-- [rfced] Section 8:  As we see that the two instances of "we" in
> RFC 8829 were changed to "this specification" and "one", we changed
> "your" to "an application's", per the next sentence.  Please let us
> know if this is incorrect.
> 
> Original (the next sentence is included for context):
> Thus,
> for instance, it is not possible to prevent the remote peer from
> learning your public IP address by removing server-reflexive
> candidates.  Applications that wish to conceal their public IP
> address MUST instead configure the ICE agent to use only relay
> candidates.
> 
> Currently:
> Thus,
> for instance, it is not possible to prevent the remote peer from
> learning an application's public IP address by removing server-
> reflexive candidates.  Applications that wish to conceal their public
> IP address MUST instead configure the ICE agent to use only relay
> candidates. -->
> 
> 
> 18) <!-- [rfced] The following Normative References have been obsoleted.
> Would you like to update the following and point to the newer RFCs?
> 
> RFC 4566 (obsoleted by RFC 8866) (Please see also
>   <https://github.com/rtcweb-wg/jsep/issues/925>.)
> 
>   If you want to cite RFC 8866 instead, it appears that
>   '"RTP/AVP" (defined in [RFC4566], Section 8.2.2)' would need to be
>   changed to '"RTP/AVP" (defined in [RFC8866], Section 8.2.3)', due
>   to a new Section 8.2.1 ("Registration Procedure") that was added
>   in RFC 8866.
> 
>   Two complications related to citing RFC 8866 would be that
>   (1) Section 6 in RFC 8866 was broken out into quite a few
>   subsections and (2) we see that in RFC 8866 "k=" is listed as
>   obsolete (so it's not clear to us whether or not that change would
>   impact the two instances of "k=" that we see in this document).
> 
>   Even though citing RFC 8866 might not be worthwhile, we thought
>   that we should point it out all the same.
> 
> 
> RFC 5285 (obsoleted by RFC 8285) (Please see also
>   <https://github.com/rtcweb-wg/jsep/issues/898>.)
> 
>   If you want to cite RFC 8285 instead of RFC 5285, it appears that
>   the two instances of "[RFC5285], Section 6" might need to be
>   changed to "[RFC8285], Section 7", due to a new Section 6 ("SDP
>   Signaling for Support of Mixed One-Byte and Two-Byte Header
>   Extensions") that was added in RFC 8285.
> 
> 
> RFC 6347 (obsoleted by RFC 9147) (Could the two instances of
>   "DTLS [RFC6347]" in this document be changed to
>   "DTLS 1.2 [RFC6347] or DTLS 1.3 [RFC9147]"?) -->
> 
> 
> 19) <!-- [rfced] Informative References:  The provided URL for
> [W3C.webrtc] steers to a page with a red banner that says "This
> version is outdated!"  As the latest version also mentions the
> RTCPeerConnection interface, may we update as follows?
> 
> Original:
> [W3C.webrtc]
>            Jennings, C., Ed., Boström, H., Ed., and J. Bruaroey, Ed.,
>            "WebRTC 1.0: Real-time Communication Between Browsers",
>            World Wide Web Consortium Recommendation, January 2021,
>            <https://www.w3.org/TR/2021/REC-webrtc-20210126/>.
> 
> Perhaps:
> [W3C.webrtc]
>            Jennings, C., Ed., Castelli, F., Ed., Boström, H., Ed.,
>            and J-I. Bruaroey, Ed., "WebRTC: Real-time Communication
>            in Browsers", W3C Recommendation, 6 March 2023, 
>            <https://www.w3.org/TR/2023/REC-webrtc-20230306/>. -->
> 
> 
> 20) <!-- [rfced] Informative References:  The listing for [TS26.114]
> appears to be out of date.  As we also see "Coordination of Video
> Orientation (CVO)" discussed in a downloaded copy of Release 18,
> may we update as suggested?
> 
> Original:
> [TS26.114] 3GPP, "3rd Generation Partnership Project; Technical
>            Specification Group Services and System Aspects; IP
>            Multimedia Subsystem (IMS); Multimedia Telephony; Media
>            handling and interaction (Release 16)", 3GPP TS 26.114
>            V16.3.0, September 2019,
>            <https://www.3gpp.org/DynaReport/26114.htm>.
> 
> Suggested:
> [TS26.114] 3GPP, "3rd Generation Partnership Project; Technical
>            Specification Group Services and System Aspects; IP
>            Multimedia Subsystem (IMS); Multimedia Telephony; Media
>            handling and interaction (Release 18)", 3GPP TS 26.114
>            V18.1.0, December 2022,
>            <https://www.3gpp.org/DynaReport/26114.htm>. -->
> 
> 
> 21) <!-- [rfced] Table 1 (Appendix A):  We could not find any of the five
> attributes listed below in Section 9 of RFC 4566.  Should Section 6
> of RFC 4566 be cited instead (or, if you wish to cite RFC 8866
> instead, a specific subsection of its Section 6, e.g., Section 6.7.1
> of RFC 8866 for "recvonly")?
> 
> Original (dashed lines broken to avoid confusion with XML comments):
> | recvonly                | Section 9 of [RFC4566]   |
> +- - - - - - - - - - - - -+- - - - - - - - - - - - - +
> | sendrecv                | Section 9 of [RFC4566]   |
> +- - - - - - - - - - - - -+- - - - - - - - - - - - - +
> | sendonly                | Section 9 of [RFC4566]   |
> +- - - - - - - - - - - - -+- - - - - - - - - - - - - +
> | inactive                | Section 9 of [RFC4566]   |
> +- - - - - - - - - - - - -+- - - - - - - - - - - - - +
> | fmtp                    | Section 9 of [RFC4566]   | -->
> 
> 
> 22) <!-- [rfced] Acknowledgements:  As this document doesn't appear to
> represent significant changes to RFC 8829, should the instances of
> "this document" be "RFC 8829 (and, by extension, this document)"?
> 
> Original:
> Harald Alvestrand, Taylor Brandstetter, Suhas Nandakumar, and Peter
> Thatcher provided significant text for this document.  Bernard Aboba,
> Adam Bergkvist, Jan-Ivar Bruaroey, Dan Burnett, Ben Campbell, Alissa
> Cooper, Richard Ejzak, Stefan Håkansson, Ted Hardie, Christer
> Holmberg, Andrew Hutton, Randell Jesup, Matthew Kaufman, Anant
> Narayanan, Adam Roach, Robert Sparks, Neil Stratford, Martin Thomson,
> Sean Turner, and Magnus Westerlund all provided valuable feedback on
> this document. -->
> 
> 
> 23) <!-- [rfced] Per our current process, please review the "Inclusive
> Language" portion of the online Style Guide at
> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
> and let us know if any changes are needed.
> 
> For example, please consider whether the following should be updated: 
> 
> whitespace ("where leading whitespace indicates ...")
> 
> he, his, him, and her (in the context of the long-used
>   Bob (/ Carol / Ted /) Alice examples)
> 
> In addition, please consider whether "traditional" ("in traditional
> SIP") should be updated for clarity.  While the NIST website 
> (<https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>)
> indicates that "traditional" is potentially biased, it is also
> ambiguous.  "Traditional" is a subjective term, as it is not the same
> for everyone. -->
> 
> 
> 24) <!-- [rfced] Please let us know if any changes are needed for the
> following:
> 
> a) The following terms were used inconsistently in this document.
> We chose to use the latter forms.  Please let us know any objections.
> 
> a "m=" (1 instance) / an "m=" (22 instances) (per RFC 8829)
> 
> SDP Offer / SDP offer (1 instance each in original)
>   ("SDP offer" was used more often in Cluster 238 (the "RTCWEB"
>    cluster), and we only see "SDP answer" in this document.)
> 
> set to null (2 instances in original) /
>   set to "null" (4 instances in original)
> 
> Source RTP stream (1 instance) / Source RTP Stream (4 instances)
> 
> b) The following terms appear to be used inconsistently in this
> document.  Please let us know which form is preferred.
> 
> BUNDLE (3 instances in Section 1.3 and one newly capitalized
>   instance in Section 4.1.1) / bundle (28 instances in text)
> 
> For example, we see this mixed usage ("use of BUNDLE", "to
> negotiate bundle", "accepting bundle") in Section 4.1.1:
> 
>  The application can specify its preferred policy regarding the use of
>  BUNDLE, the multiplexing mechanism defined in [RFC9143].  Regardless
>  of policy, the application will always try to negotiate bundle onto a
>  single transport and will offer a single bundle group across all "m="
>  sections; use of this single transport is contingent upon the
>  answerer accepting bundle.
> 
> We see that "bundle group" and "bundle policy" are used consistently.
> 
> 
> CN codecs (1 instance in Section 5.3.3.1) /
>   "CN" codecs (2 instances in Section 5.2.3.2)
>   (We also found this inconsistency in RFC 8829.)
> 
> 
> Full Trickle (Section 4.1.17) / full trickle (mode) (Section 7.2)
>   (We also see "Half Trickle" in this document.  However, we see
>   "half trickle" and "full trickle" in RFC 8838, and "Half Trickle"
>   and "Full Trickle" in RFC 8840.)
> 
> 
> ICE-lite / ice-lite
>   ("endpoints that use ICE-lite", "the presence of ice-lite")
> 
>   (Perhaps 'the presence of an "a=ice-lite" line'?)
> 
> 
> mid identifiers (2 instances) / MID identifiers (3 instances)
> 
>   (This question was also asked during AUTH48 for RFC 8829 and
>   appears to apply to this document and RFC 8829 only.  Please see
>   <https://github.com/rtcweb-wg/jsep/issues/959>, and let us know
>   how the capitalization of this term should be made consistent.)
> 
> 
> port value / <port> value (e.g., "default port value of 9 (Discard)",
>   "default <port> value of 9 (Discard)")
> 
> (We also see 2 instances of "SCTP port value".)
> 
> 
> c) Quoting of terms:
> 
> We see that most option names are quoted (e.g., '"trickle" option',
> '"ice2" option', '"VoiceActivityDetection" option').  Would you like
> to put quotes around "IceRestart" ('"IceRestart" option') as well?
> 
> We also see the unquoted "VoiceActivityDetection parameter" in
> Section 5.3.3.1; could this be changed to '"VoiceActivityDetection"
> option'?
> 
> 
> Should quoting of named media formats and directions be consistent?
> For example, we see
> 
> "rtx" media format
> send media format
> "send" and "recv" directions
> a "recvonly" direction
> a recvonly direction
> mark the "m=" section associated with the sender as recvonly (if
>   transceiver.direction is sendrecv) or as inactive (if
>   transceiver.direction is sendonly)
> sendrecv or sendonly direction
> offered as "sendonly"
> marked as sendonly/inactive
> marks them as sendonly
> creating recvonly transceivers
> If the "m=" section is sendrecv or recvonly
> handled as recvonly -->
> 
> 
> Thank you.
> 
> RFC Editor/lb/ar
> 
> 
> On Oct 10, 2023, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2023/10/10
> 
> RFC Author(s):
> --------------
> 
> Instructions for Completing AUTH48
> 
> Your document has now entered AUTH48.  Once it has been reviewed and 
> approved by you and all coauthors, it will be published as an RFC.  
> If an author is no longer available, there are several remedies 
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> 
> You and you coauthors are responsible for engaging other parties 
> (e.g., Contributors or Working Group) as necessary before providing 
> your approval.
> 
> Planning your review 
> ---------------------
> 
> Please review the following aspects of your document:
> 
> *  RFC Editor questions
> 
>  Please review and resolve any questions raised by the RFC Editor 
>  that have been included in the XML file as comments marked as 
>  follows:
> 
>  <!-- [rfced] ... -->
> 
>  These questions will also be sent in a subsequent email.
> 
> *  Changes submitted by coauthors 
> 
>  Please ensure that you review any changes submitted by your 
>  coauthors.  We assume that if you do not speak up that you 
>  agree to changes submitted by your coauthors.
> 
> *  Content 
> 
>  Please review the full content of the document, as this cannot 
>  change once the RFC is published.  Please pay particular attention to:
>  - IANA considerations updates (if applicable)
>  - contact information
>  - references
> 
> *  Copyright notices and legends
> 
>  Please review the copyright notice and legends as defined in
>  RFC 5378 and the Trust Legal Provisions 
>  (TLP – https://trustee.ietf.org/license-info/).
> 
> *  Semantic markup
> 
>  Please review the markup in the XML file to ensure that elements of  
>  content are correctly tagged.  For example, ensure that <sourcecode> 
>  and <artwork> are set correctly.  See details at 
>  <https://authors.ietf.org/rfcxml-vocabulary>.
> 
> *  Formatted output
> 
>  Please review the PDF, HTML, and TXT files to ensure that the 
>  formatted output, as generated from the markup in the XML file, is 
>  reasonable.  Please note that the TXT will have formatting 
>  limitations compared to the PDF and HTML.
> 
> 
> Submitting changes
> ------------------
> 
> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
> the parties CCed on this message need to see your changes. The parties 
> include:
> 
>  *  your coauthors
> 
>  *  [e-mail] (the RPC team)
> 
>  *  other document participants, depending on the stream (e.g., 
>     IETF Stream participants are your working group chairs, the 
>     responsible ADs, and the document shepherd).
> 
>  *  [e-mail], which is a new archival mailing list 
>     to preserve AUTH48 conversations; it is not an active discussion 
>     list:
> 
>    *  More info:
>       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> 
>    *  The archive itself:
>       https://mailarchive.ietf.org/arch/browse/auth48archive/
> 
>    *  Note: If only absolutely necessary, you may temporarily opt out 
>       of the archiving of messages (e.g., to discuss a sensitive matter).
>       If needed, please add a note at the top of the message that you 
>       have dropped the address. When the discussion is concluded, 
>       [e-mail] will be re-added to the CC list and 
>       its addition will be noted at the top of the message. 
> 
> You may submit your changes in one of two ways:
> 
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
> 
> Section # (or indicate Global)
> 
> OLD:
> old text
> 
> NEW:
> new text
> 
> You do not need to reply with both an updated XML file and an explicit 
> list of changes, as either form is sufficient.
> 
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text, 
> and technical changes.  Information about stream managers can be found in 
> the FAQ.  Editorial changes do not require approval from a stream manager.
> 
> 
> Approving for publication
> --------------------------
> 
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
> 
> 
> Files 
> -----
> 
> The files are available here:
>  https://www.rfc-editor.org/authors/rfc9429.xml
>  https://www.rfc-editor.org/authors/rfc9429.html
>  https://www.rfc-editor.org/authors/rfc9429.pdf
>  https://www.rfc-editor.org/authors/rfc9429.txt
> 
> Diff file of the text:
>  https://www.rfc-editor.org/authors/rfc9429-diff.html
>  https://www.rfc-editor.org/authors/rfc9429-rfcdiff.html (side by side)
> 
> Diff of the XML: 
>  https://www.rfc-editor.org/authors/rfc9429-xmldiff1.html
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>  https://www.rfc-editor.org/auth48/rfc9429
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9429 (draft-uberti-rtcweb-rfc8829bis-05)
> 
> Title            : JavaScript Session Establishment Protocol (JSEP)
> Author(s)        : J. Uberti, C. Jennings, E. Rescorla, Ed.
> WG Chair(s)      : Sean Turner, Ted Hardie
> Area Director(s) : Murray Kucherawy, Francesca Palombini