Ballot for draft-ietf-rtcweb-sdp
Yes
No Objection
No Record
Note: This ballot was opened for revision 12 and is now closed.
Please respond to the GenART review. Although it raised no major or minor issues, the list of nits was extensive.
[[ 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"
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/
Please respond to the Gen-ART review. I agree with Roman that the use of normative language seems inappropriate in this doc.
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/
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.
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
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
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.