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

[Justin Uberti <[e-mail]>]

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
>
>