Skip to main content

Annotated Example SDP for WebRTC
draft-ietf-rtcweb-sdp-14

Note: This ballot was opened for revision 12 and is now closed.

Murray Kucherawy Yes

Comment (2020-05-10 for -12)
Please respond to the GenART review.  Although it raised no major or minor issues, the list of nits was extensive.

Alvaro Retana No Objection

Comment (2020-05-19 for -12)
All the references are marked as Informative; I am surprised that none of them are considered ones "that must be read to understand...the technology in the new RFC" [1].

It seems to me that some (maybe all) of the following should be Normative references: I-D.ietf-rtcweb-jsep, WebRTC, rfc3264, rfc7656, rfc4566.

I am not balloting DISCUSS because I am definitely not an expert in the topic, so I trust the Responsible AD to make the right call.


[1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

Erik Kline No Objection

Comment (2020-05-19 for -12)
[[ nits ]]

[ abstract ]
* "mechanism" --> missing a full stop

[ section ]
* "Below figure" --> "The below figure"

[ section 4 ]
* "introduces SDP" --> "introduces the SDP"?

* "to refer RFC3264" --> "to refer to RFC3264"

* "defines protocol" --> "defines a protocol"?

* "each others" --> "each other's"

[ section 5.1 ]
* "Eventhough" --> "Even though"

* "diagrams shows" --> "diagrams show"

* "confirm to" --> "conform to"

* "Following SDP" --> "The following SDP"

* "SSRCs" --> expand SSRC on first use?

[ section 5.2.7 ]
* "the Alice" --> "Alice"

* "the Bob indicates its" --> "Bob indicate their"

[ section 5.2.9 ]
* "The same is indicated" --> "This is indicated"?

[ section 5.2.10 ]
* "show-cases" --> "showcases"

[ section 5.3.4 ]
* "2 two" --> "two"

[ section 5.3.5 ]
* "and and" --> "and"

[ Appendix A.1.2 ]
* "lip same sync" --> "same lip sync"

[ Appendix A.1.3 ]
* "An JSEP" --> "A JSEP"

Martin Duke No Objection

Comment (2020-05-20 for -12)
I am not even remotely qualified to evaluate the examples. Here are a bunch of nits instead:

Abstract: s/mechanisms/mechanisms.

Section 3:
s/Below figure/The figure below

s/convey participant’s/convey the participant’s

Section 4.

s/introduces SDP/introduces the SDP

s/in nature/in nature,

s/refer [RFC3264]/refer to [RFC3264]

s/It defines protocol/it defines a protocol

s/each others/each other’s

s/JSEP specification/The JSEP specification

Section 5.1:
s/apriori/a priori

s/intentionally is not/intentionally are not

s/In the actual use/In actual use

table 3: s/sreams/streams

Sec 5.3.4: 
s/2 two/two

Table 33. I believe the offer should reference RTX streams (plural?)

Sec 5.3.5: s/we end up/, we end up with

Sec 5.4.4: s/Bob being a WebRTC endpoint/Bob, being a WebRTC endpoint,

Sec 7: s/using TLS/using the TLS

Robert Wilton No Objection

Comment (2020-05-21 for -12)
Hi,

This document is well outside my domain of expertise, and I see no management related issues or concerns.

I have mostly only skimmed this document.  I hope that either the examples have been generated by real code, or otherwise programmatically validated in some way to ensure that they are correct.

Regards,
Rob

Roman Danyliw No Objection

Comment (2020-05-19 for -12)
Thanks for writing this document.  It is always helpful to have examples that tie together a number of specifications.

** Section 4 and 5.  I was surprised to see three place where RFC2119 language was used in the core text (i.e., not in the Appendix).  Is there a reason this particular behavior was called out here?  Is it not covered in other specifications?

-- Section 4.  The participant receiving the offer MAY generate an SDP Answer accepting the offer or it MAY reject the offer. 

-- Section 5. MAY contain zero or more non-media data sessions,

** Editorial Feedback

--  Section 1.  Recommend repeating the following text in the abstract to make it clear that this document is informative in nature: “This document provides an informational reference in describing the role of SDP and the Offer/Answer exchange mechanism for the most common WebRTC use-cases.”.  Additionally, consider adding that “This document makes no changes to the Offer/Answer exchange mechanism”.

-- Section 3.  Editorial.  s/Below figure introduces/Figure 1 introduces the/

-- Section 3.  Editorial.  Sentence uses “design” twice.   s/[WebRTC] is designed so that the design of the control plane/[WebRTC] is architected in such a way that the design of the control plane/

-- Section 5.1. Typo. s/Eventhough/Even though/

-- Section 5.1. Editorial.  s/Following SDP details/The following SDP details/

(Alissa Cooper; former steering group member) No Objection

No Objection (2020-05-20 for -12)
Please respond to the Gen-ART review.

I agree with Roman that the use of normative language seems inappropriate in this doc.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -12)

                            

(Magnus Westerlund; former steering group member) (was Discuss) No Objection

No Objection (2020-12-17 for -13)
Thanks for addressing my issues. I did notice that the current text version is not keeping within the text formats limitation on lines. However, it might be that the RFC-editor is better at getting these tables to stay within limitations. I think this is one document that would benefit from a proper v3 format conversion so that we get reasonable HTML table renderings of the examples.

(Benjamin Kaduk; former steering group member) (was Discuss) No Record

No Record (2021-01-28)
Dropping to No Record to reflect that my Discuss points on the -12
have been resolved.  The reformatting (e.g., of tables) incurred in going
from the -12 to the -14 makes reviewing the diff about as much work as
reviewing the -14 from scratch, and I don't want to delay this document
while I find the time to do so.