RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-10

This draft was really easy for me to read (with some background in RTP/RTCP, but I'm no expert on the topic). Thank you for the work on it - the results show.

I have some questions, but nothing is a show-stopper.

In this text:

3.3.  RTP Mixer to Media Sender in Point-to-Multipoint

   In this use case there are several receivers of a stream and special
   care must be taken as not to pause a stream that is still wanted by
   some receivers.
   
I'm assuming that the Mixer is taking special care, but this is passive enough that I'm filling in blanks. If you like passive voice, perhaps something like

   In this use case there are several receivers of a stream and special
   care must be taken by the Mixer so as not to pause a stream that is 
                      ^^^^^^^^^^^^^^^
   still wanted by some receivers.
   
would be easier to parse.

If you can do active voice, perhaps 

   In this use case there are several receivers of a stream and the 
   Mixer must take special care so as not to pause a stream that is still 
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   wanted by some receivers.
   
In this text:

8.  Message Details

   Any references to PAUSE, PAUSED, RESUME and REFUSED in this section
   SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
   are used (Section 5.6) for this functionality.  TMMBR/TMMBN MAY be
                                                               ^^^
   used instead of the messages defined in this specification when the
   effective topology is point-to-point.  If either sender or receiver
   learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT
   be used for pause/resume functionality.  If the messages defined in
   this specification are supported in addition to TMMBR/TMMBN by all
   involved parties, pause/resume signaling MUST use messages from this
   specification.  If the topology is not point-to-point and the
   messages defined in this specification are not supported, pause/
   resume functionality with TMMBR/TMMBN MUST NOT be used.
   
All of this makes sense to me, except that I'm not understanding why TMMBR/TMMBN is a MAY. There's a lot of text that says you really need to use the messages from this specification in this case, and in that case, and ... but here, you MAY do something else.

I understand that TMMBR/TMMBN works in a point-to-point topology, but is there a reason to prefer TMMBR/TMMBN in that topology? If so, it would probably be good to explain why.

And as I read futher, I see this, in section 9:

      Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
      resume functionality (with the restrictions described in this
      specification), signaling rtcp-fb attribute with ccm tmmbr
      parameter is sufficient and no further signaling is necessary.
      There is however no guarantee that TMMBR/TMMBN implementations
                       ^^^^^^^^^^^^
      pre-dating this specification work exactly as described here when
      used with a bitrate value of 0.
      
and that really makes me wonder why this specification is also describing TMMBR/TMMBN. I'm sure there's a good reason, but can you understand my confusion?

Finally, I see this, in section 9.1,

   If both "pause" and "tmmbr" are present in the offer, both MAY be
   included also in the answer, in which case TMMBR/TMMBN MUST NOT be
   used for pause/resume purposes (with a bitrate value of 0), to avoid
   signaling ambiguity.
   
and in section 9.2,

   If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST
   NOT be used for pause/resume purposes (with a bitrate value of 0), to
   avoid signaling ambiguity.
   
I'm now wondering if the description of TMMBR/TMMBN in this specification just for interworking with older implementations that don't support PAUSE/RESUME but figured out how to get a similar effect with TMMBR/TMMBN? 

I'm guessing, of course :-)

In this text:

8.5.  Transmission Rules

   o  PAUSE SHOULD use Early or Immediate timing, except for
      retransmissions that SHOULD use Regular timing.
      
^ I understand this one.

   o  The first transmission of PAUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      PAUSED for that PauseID SHOULD use Regular timing.  Unsolicited
      PAUSED (sent when entering Local Paused State (Section 6.4))
      SHOULD always use Immediate or Early timing, until PAUSED for that
      PauseID is considered delivered at least once to all receivers of
      the paused RTP stream, after which it SHOULD use Regular timing.

^ I'm wondering why these are SHOULDs. Are they MUSTs except that some implementations don't do it, or recommendations but nothing breaks if you don't do them, or something else?

   o  RESUME SHOULD always use Immediate or Early timing.

^ I wonder why this is SHOULD. Is there any guidance you can provide about why RESUME would use Regular timing?

   o  The first transmission of REFUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      REFUSED for that PauseID SHOULD use Regular timing.

^ I am, of course, wondering about the corresponding SHOULDs for REFUSED.

In this text:

9.  Signaling

   When signaling a config value other than 1, an implementation MUST
   ignore non-supported messages on reception, and MAY omit sending non-
   supported messages.
   
is this saying that an implementation might send non-supported messages? I'm confused here.