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

[[e-mail]]

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