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

[Cullen Jennings <[e-mail]>]

> On Oct 27, 2023, at 11:42 PM, Murray S. Kucherawy <[e-mail]> wrote:
> 
> Justin, or chairs: Would you like to delegate the completion of AUTH48 to someone else?
> 

I am doing review but may not happen until IETF. Sorry 



> -MSK
> 
> 
> On Fri, Oct 27, 2023 at 10:02 AM Lynne Bartholomew <[e-mail]> wrote:
> Dear authors,
> 
> Checking in with you regarding the status of this document.
> 
> Thank you!
> 
> RFC Editor/lb
> 
> > On Oct 17, 2023, at 8:58 AM, Justin Uberti <[e-mail]> wrote:
> > 
> > Thanks for the ping. Will send an initial response later this week once I’ve had a chance to go through all the comments.
> > 
> > On Tue, Oct 17, 2023 at 8:56 AM Sean Turner <[e-mail]> wrote:
> > 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
> > 
>