Reviewer: Vijay Gurbani Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-avtcore-multiplex-guidelines-?? Reviewer: Vijay K. Gurbani Review Date: 2019-04-15 IETF LC End Date: 2019-04-10 IESG Telechat date: Not scheduled for a telechat Summary: Ready for informational with some minor issues that should be looked at, and some nits. Major issues: 0 Minor issues: 3 Nits/editorial comments: various - Minor: - S3.2.1, third paragraph: Here, is the assumption that the "single endpoint" has multiple network attachments, each with its own IP address? If so, perhaps it is better to say so. The text talks about multiple UDP flows being identified by their UDP source port and destination IP address, however, if the "single endpoint" has only one network attachment, isn't the port number enough to identify the flows? I know it can get arbitrarily complex if multiple IP addresses are bound to the single network attachment point, etc., however, the intent of this document is to reduce ambiguity around RTP multiplexing, so it is best that it lays out its assumptions in detail so as to not add to the noise. - S3.2.4, first paragraph: We should not use the term "whatever" in a standards document. My suggestion would be to rewrite the offending sentences(s) as follows: OLD: The term "format" here includes whatever can be described by out-of-band signalling means. In SDP, the term "format" includes media type, RTP timestamp sampling rate, codec, codec configuration, payload format configurations, and various robustness mechanisms such as redundant encodings [RFC2198]. NEW: The term "format" here includes any artifacts described by out-of-band signalling means; in SDP, the term "format" includes media type, RTP timestamp sampling rate, codec, codec configuration, payload format configurations, and various robustness mechanisms such as redundant encodings [RFC2198]. - S4.1.1, first and second paragraphs: There is an overuse of "one" or "ones" in this paragraph. In different context, "one" may refer to a person or it may refer to a way of enumerating or counting some things. It is not clear what is being referred to here by using "one". For example, "where one want to interconnect", here is it the one referring to one of the many applications? Or is it referring to a user? - Nits: - S1: s/implications that come from/implications arising from/ - S1: I am not sure why it is worth highlighting that "The document will highlight against as some usages being unsuitable, ..." If it is worth stating this, then perhaps it is also worth stating that the document will also highlight usages that are suitable. If on the other hand, the existing text in the document is a warning to implementors who are using RTP in a way not intended, then perhaps best to say that "The document will highlight against some prevalent usages of RTP multiplexing as unsuitable, ..." - S2.2, second sentence: Perhaps best to include references for SIP and Jingle. - S3.1: Please expand FEC (Forward Error Correction) on first use. - S3.2.1: s/yet, RTP sessions must be possible to separate both across /yet, RTP sessions must be separable across/ - S3.2.1: s/media descriptions, for example used/media descriptions, for example, to be used/ OR s/media descriptions, for example used/media descriptions to be used/ - S3.2.2, end of page 9: s/(and should not)/(and, indeed, should not)/ (Highlight that the existing usage is wrong). - S3.2.2, top of page 10: s/SSRC, so the new SSRC/SSRC, making the new SSRC/ - S3.2.4, page 11: "at any time instant" ==> Do you mean "at any time instance"? If so, there are a couple of occurrences of "time instant" in that paragraph that should be changed. - S3.3, page 12: "If the stream transport ... or media adaptation." This sounds like a warning, if so, I would preface the sentence as follows: "Beware that changing the stream transport characteristics..." You will have to reword the rest of the sentence appropriately. - S3.3, last paragraph: Is what is described in that paragraph okay? Nothing bad will happen, right? The intent of this document is to reduce ambiguities in RTP multiplexing, so if this paragraph does not result in an undesirable outcome, then perhaps it makes sense to say so. In its current form, the paragraph is asserting a statement without providing any hints on whether or not the statement is accurate. - S3.4.1, page 14: "As we saw in the discussion of RTP mixers, ..." => Perhaps provide a reference to the RTP mixing section; I tried to find it, but was not sure which section is being referenced here. - S3.4.1, page 14: s/we will discuss more below/we will discuss below/ - S3.4.3: s/or resource consuming/or a drain on resources/ - S3.4.4: s/see very heterogeneous/see heterogeneous/ - S4.1.2: s/even if no participants/even if none of the participants/ - S4.2.2, page 22: "... as some stack implementations." => Which "stack"? RTP stack or some other stack. Please specify. - S4.3.1, first paragraph: The sentence, "At least unless ... achieve source authentication." appears to be a fragment not tied to any of the succeeding or preceding sentences. Perhaps you may want to reword it, or make it part of the neighbouring sentences. - S5.1 to S5.4: My advice would be to s/The Pros:/The advantages:/ and s/The Cons:/The disadvantages:/ (Reason: Pros and Cons are more colloquial usage of the terms, in a standard document it is better, at least in my opinion, to be more formal.) - S5.1: - s/that uses individual/that use individual/ - s/the RTP streams'/the RTP stream's/ - S6, page 32: delete the extra line after "Use additional RTP sessions for streams with different requirements:" - Appendix A: s/for most things/for most issues/ - Appendix A: s/If one attempts to use Payload type multiplexing beyond its defined usage, that has well known negative effects on RTP./Attempting to use Payload type multiplexing beyond its defined usage has well known negative effects on RTP./ (You may want to provide a reference to where such "well known negative effects on RTP" are documented.) - Appendix B: s/it is hugely important/it is extremely important/ (Reason: "hugely" is a colloquial term.) - Appendix B, second paragraph: I think that this paragraph is important since it is asking WGs to do something specific at some time, and it is documenting the current behaviour that the WG should change. As such, I would advise that the gravity of this be provided accordingly. The suggested paragraph below can replace the existing paragraph (subject to your editorial discretion, of course): We document salient issues here that need to be addressed by the WGs that use some form of signaling to establish RTP sessions. These issues cannot simply be addressed by tweaking, extending, or profiling RTP, but require a dedicated and indepth look at the signaling primitives that set up the RTP sessions. - Appendix B.1: - s/focused around/focused on/ - s/potentially useful to signal not only on/potentially useful beyond/
