[AVTCORE] Genart last call review of draft-ietf-avtcore-multiplex-guidelines-08

[Vijay Gurbani via Datatracker <[e-mail]>]

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/