Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti-rtcweb-rfc8829bis-05> for your review
Lynne Bartholomew <lbartholomew@amsl.com> Fri, 27 October 2023 17:02 UTC
Return-Path: <lbartholomew@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E43C15152B; Fri, 27 Oct 2023 10:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDJMbiLX71s0; Fri, 27 Oct 2023 10:02:00 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0B6C14CE25; Fri, 27 Oct 2023 10:02:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 5B045424B434; Fri, 27 Oct 2023 10:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxcxQRGBIDbA; Fri, 27 Oct 2023 10:02:00 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2601:646:9882:8ac0:a849:b1df:6f7f:e822]) by c8a.amsl.com (Postfix) with ESMTPSA id 1B75D424B42D; Fri, 27 Oct 2023 10:02:00 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
From: Lynne Bartholomew <lbartholomew@amsl.com>
In-Reply-To: <CALe60zDCVFXta=sP==0cTgNwAQO=rKitsE3P_PyCkM40025fzQ@mail.gmail.com>
Date: Fri, 27 Oct 2023 10:01:49 -0700
Cc: Sean Turner <sean@sn3rd.com>, "Murray S. Kucherawy" <superuser@gmail.com>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, auth48archive <auth48archive@rfc-editor.org>, rtcweb-ads@ietf.org, rtcweb-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C755352-92A9-4EA8-A43E-F7152FA77025@amsl.com>
References: <20231010213257.4587F18E4B44@rfcpa.amsl.com> <AB83C76D-AD71-455B-85DA-C561F5AC7F27@sn3rd.com> <CALe60zDCVFXta=sP==0cTgNwAQO=rKitsE3P_PyCkM40025fzQ@mail.gmail.com>
To: Justin Uberti <justin@uberti.name>, fluffy@iii.ca, Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/zQLVJKcB4wC8sZ8xH40qIRbr968>
Subject: Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti-rtcweb-rfc8829bis-05> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Oct 2023 17:02:05 -0000
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 <justin@uberti.name> 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 <sean@sn3rd.com> wrote: > Checking in to make sure everybody has seen these. > > spt > > > On Oct 10, 2023, at 17:32, rfc-editor@rfc-editor.org 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, rfc-editor@rfc-editor.org 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 > > > > * rfc-editor@rfc-editor.org (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). > > > > * auth48archive@rfc-editor.org, 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, > > auth48archive@rfc-editor.org 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 >
- [auth48] AUTH48: RFC-to-be 9429 <draft-uberti-rtc… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Sean Turner
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Murray S. Kucherawy
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Murray S. Kucherawy
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <draft-… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Murray S. Kucherawy
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Sean Turner
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Cullen Jennings
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Sean Turner
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Justin Uberti
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Justin Uberti
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Cullen Jennings
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Cullen Jennings
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Ted Hardie
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Ted Hardie
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Sean Turner
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Sean Turner
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Ted Hardie
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew