Re: [AVTCORE] AD Evaluation of draft-ietf-avtcore-multiplex-guidelines-08 - editorial comments part

[Bo Burman <[e-mail]>]

This is the response to editorial comments in the AD review, inline below.
My response to the substantial comments was sent in a separate mail.
Cheers,
/Bo

> -----Original Message-----
> From: Ben Campbell <[e-mail]>
> Sent: den 27 mars 2019 15:26
> To: [e-mail]
> Cc: Barry Leiba <[e-mail]>
> Subject: AD Evaluation of draft-ietf-avtcore-multiplex-guidelines-08
> 
> Hi,
> 
> This is my AD evaluation of draft-ietf-avtcore-multiplex-guidelines-08.
> 
> I have a few material comments and a number of editorial comments. I don’t
> think any of these need block IETF LC. They can be handled along with any
> other IETF LC feedback.
> 
> Also, Barry will become the responsible AD after today, so the resolution of
> my comments will be at his discretion.
> 
> Thanks!
> 
> Ben.
> 
> ————————————————
> 
> *** Substantive Comments ***
[BoB] Answered in separate mail
<cut>

> *** Editorial Comments ***
> 
> - General:
> 
> — The doc spends more words on analysis than it does on guidance. It might
> be worth reconsidering the title.
[BoB] I believe the analysis is an important background and motivation for how the guidelines are chosen, since the area is often misunderstood.

> -- Parts of this seem unnecessarily wordy. Please edit for “null words” (For
> example “It should be noted that…”, “A general observation is…”, and “It is
> worth pointing out…")
[BoB] I've made a pass through the document will try to remove such wordiness in -09

> 
> §1, 2nd paragraph: "The limitations in
> some implementations, RTP/RTCP extensions, and signalling has also been
> exposed. The authors also hope that clarification on the usefulness of some
> functionalities in RTP will result in more complete implementations in the
> future.”
> 
> First sentence: s/has/have
[BoB] OK

> 2nd sentence: “also” seems out of place (the authors hope this in addition to
> what?)
[BoB] Removed

> 
> §2.1: "Note: The above definitions of RTP Receiver and RTP sender are
> intended to be consistent with the usage in [RFC3550].”
> 
> Now that the section is written, did the authors succeed in this intent? Or is
> there a concern it might not be consistent?
[BoB] No concern. Suggest to just say they're consistent.

> 
> §3.1: Expand FEC on first mention.
[BoB] OK

> 
> §3.2.1:
> 
> - "An RTP Session is the highest semantic layer in the RTP protocol, and
> represents an association between a group of communicating endpoints.
> RTP does not contain a session identifier, yet RTP sessions must be possible
> to separate both across different endpoints and within a single endpoint.”
> 
> I do not understand the last clause in the sentence.
[BoB]  Is "RTP does not contain a session identifier, yet different RTP sessions
   must be possible to identify both across different endpoints and
   within a single endpoint" more clear?

> 
> - "A single
> endpoint can have one or more transport flows for the same RTP session,
> and a single RTP session can span multiple transport layer flows.”
> 
> Isn’t the second part entirely implied by the first?
[BoB] It is, but anyway believe the second part is important to highlight. What about
" A single
   endpoint can have one or more transport flows for the same RTP
   session, and a single RTP session can therefore span multiple
   transport layer flows even if all endpoints use a single transport
   layer flow per endpoint for that RTP session."?

> 
> - "For example, when running RTP on top of UDP/IP, an endpoint can identify
> and delimit an RTP session from other RTP sessions by receiving the multiple
> UDP flows used as identified based on their UDP source and destination IP
> addresses and UDP port numbers.”
> 
> I don’t understand that sentence. (something is wrong around “flows used
> as identified based”)
[BoB] Suggest simply removing the middle part of the sentence, which then becomes:
"For example, when running RTP on top of UDP/IP, an endpoint can identify
and delimit an RTP session from other RTP sessions by their UDP source and destination IP
addresses and UDP port numbers."

> 
> - "SDP grouping framework [RFC5888] allows labeling…”
> Missing article before SDP
[BoB] OK

> 
> - "With Negotiating Media Multiplexing Using the Session Description
> Protocol (SDP)[I-D.ietf-mmusic-sdp-bundle-negotiation],
> multiple media descriptions where each represents the RTP streams sent or
> received for a media source are part of a common RTP session.”
> 
> Convoluted sentence
[BoB] Suggest re-phrasing:
" Through use of Negotiating Media Multiplexing Using the
   Session Description Protocol (SDP)
   [I-D.ietf-mmusic-sdp-bundle-negotiation], multiple media descriptions
   become part of a common RTP session where each media description
   represents the RTP streams sent or received for a media source."

> 
> §3.2.2: "An endpoint that changes its network transport address during a
> session have to choose a new SSRC identifier to avoid being interpreted as
> looped source...”
> 
> s/have/has  (plural mismatch)
[BoB] OK

> 
> §3.4.1:
> 
> - "One type
> of application that can mix different media sources "blindly" is the audio-only
> "telephone" bridge; most other types of applications need application-
> specific logic to perform the mix correctly.”
> 
>  I think this is an argument that the fourth argument is invalid, but that’s not
> clear from the text. Also, why the scare quotes?
[BoB] It is not an argument that the fourth argument is invalid, but that the audio-only telephone bridge is an example where seemingly incompatible streams (in terms of codecs etc.) are in fact compatible on the application level due to the well-defined scenario, aided by the use of a single media type. I'll add a few words on that. I'll also remove the scare quotes.

> 
> §3.4.3:
> 
> - "These has previously been considered primarily as grouping RTP sessions,
> [I-D.ietf-mmusic-sdp-bundle-negotiation] groups multiple media
> descriptions as a single RTP session”
> 
> plural disagreement between “these” and “has”.
[BoB] OK

> 
> - "This supports a lot of use cases.”
> 
> What is the antecedent of “this”? Should “this” be “these”?
[BoB] Suggest to be more explicit and instead say "The above grouping constructs support many use cases".

> 
> - "For
> applications with a single RTP stream per type (Media, Source or
> Redundancy) this is sufficient independent if one or more RTP sessions are
> used.”
> 
> I don’t understand the sentence. Also, later in that paragraph I got lost in all
> the instances of “this” with apparently different antecedents.
[BoB] It relates to the RTP/RTCP-based grouping provided by RTCP SDES CNAME. The same is true for most occurrences of "this" in that paragraph. I'll make that text more explicit and hopefully more clear.

> 
> - "Therefore, it is not recommended to use identical SSRC values to relate
> RTP streams.”
> 
> This kind of buried the lede. I suggest saying that first, then explaining why.
[BoB] OK.

> 
> - "It can be noted that Section 8.3 of the RTP Specification…”
> “It can be noted” are null words.
[BoB] Removed.

> 
> §3.4.4:
> 
> - "Most of
> the FEC schemes will protect…”
> 
> Inconsistent tense. I suggest sticking to present tense.
[BoB] OK

> 
> - "This
> sequence of redundant information also needs to be transmitted as its own
> media stream”
> 
> I’m not sure what “also” adds here.
[BoB] Removed.

> 
> - "By
> placing it in a separate RTP session and if separating RTP sessions on
> transport level, FEC can easily be ignored already on transport level.”
> 
> I don’t understand this sentence. Is something broken around “ignored
> already”?
[BoB] Don't think so. Does it become more clear if adding " , without considering any RTP layer information" at the end of the sentence?

> 
> §4.1: "There are several different kinds of interworking, and this section
> discusses two; interworking between different applications including the
> implications of potentially different RTP multiplexing point choices and
> limitations that have to be considered when working with some legacy
> applications.”
> 
> It’s not clear to me that this talks about two different kinds of interworking.
[BoB] OK. I'll clarify that this talks about interworking directly between different applications and interworking of applications through an RTP Translator.

> 
> §4.1.1: "There are two fundamental approaches to building a gateway: using
> an RTP Translator interworking (RTP bridging),”
> 
> Are there missing words around “an RTP Translator interworking"
[BoB] Don't think so. Suggest removing "an", to emphasize that it is the RTP Translator (type of) interworking that is used and not so much using the RTP Translator itself.

> 
> §4.1.4: "This indicates that gateways attempting to interconnect to this class
> of devices has”
> Plural mismatch between “gateways” and “has”
[BoB] OK

> 
> §4.2.2: "However, it is worth pointing out that a real-time video conference
> session with audio and video is likely using less than”
> 
> s/“is likely using”/“likely uses”
[BoB] OK

> 
> §4.2.3
> 
> - "Another
> application is the Many to Many communication, which RTP [RFC3550] was
> originally built to support, but the multicast semantics do result in a certain
> number of limitations.”
> I'm confusedby that sentence. the the limitations specific to many-to-many,
> or to multicast in general?
[BoB] Suggest to re-phrase as " Many-to- many communication, which RTP [RFC3550] was originally built to support, has several limitations in common with multicast"

> 
> - "result in a certain number of limitations.
> One limitation is that for any group, sender side adaptation to the actual
> receiver properties causes degradation for all participants to what is
> supported by the receiver with the worst conditions among the group
> participants.”
> 
> Hard to parse.
[BoB] Suggest re-phrasing to " One limitation is that, for any group, sender side adaptation with the intent to suit all receivers would have to adapt to the most limited receiver experiencing the worst conditions among the group participants, which imposes degradation for all participants."


> 
> §4.3.1:
> 
> - "At least unless TESLA source authentication [RFC4383], which adds delay to
> achieve source authentication.”
> 
>  Does not parse. Missing words?
[BoB] Likely. Suggest "At least unless TESLA source authentication [RFC4383] is used, which adds delay to achieve source authentication.”

> 
> - "A second case is when using security as an enforcing mechanism for
> differentiation.”
> 
>  I'm not sure what this means
[BoB] Suggest clarifying to "A second case is when using security as an enforcing mechanism for stream access differentiation between different receivers."

> 
> §5 and subsections:
> 
> Please be consistent about whether the “pros” and “cons” use complete
> sentences or fragments.
[BoB] OK

> 
> §5.3, Con A: This is not so much a con but a design decision. It’s only a con in
> the sense of the other cons that it creates.
[BoB] True. Suggest merging Con A and B.

> 
> Con F is hard to parse.
[BoB] Suggest re-phrasing the first part of the sentence to: "If the applications need more fine-grained control than per RTP session over which participants that are included..."

> 
> - Appendix A:
> 
> - 2nd sentence: Improper capitalization of “Payload”.
[BoB] OK

> - list item 1: s/restraint/constraints
[BoB] OK