Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)
draft-ietf-avtcore-idms-13

Version -13 addresses all of my comments.  Thanks very much for considering them.

I support Spencer's DISCUSS.  The text in question can be tightened up to ensure interoperability.

This is a nervous "No objection". I'd be a lot more comfortable if I knew that NTP folks had worked on, or at least reviewed, this document. Did that take place? If not, a review in NTP should definitely be solicited. I'm an NTP amateur, but certain parts of this document caused my eyebrows to raise.

Section 3: What does "indicate requirement levels for compliant implementations" mean exactly? That doesn't sound like what 2119 means.

Section 5, last paragraph: Though I agree with Richard that "wallclock" is now a well-used enough term in these circles to leave it in there, I think the claim that it is *necessary* for wallclocks to be synchronized is actually incorrect. It is certainly a straightforward and effective way to implement this, but I think I could alternatively come up with a pretty easy way for Alice and Bob to simply have relative offset to the media server's time, but not to each other and not to some reference time, and still be able to sync the media. See comment on section 9 below.

Section 7, third paragraph: I don't understand the SHOULDs in this paragraph. For example, in the first sentence are you saying that SCs are *only* to report on recently received packets and SHOULD NOT report on old ones? Or are you saying that it SHOULD report whenever it receives packets and not delay reports? I don't understand what this means. I have similar questions about the SHOULD in the third sentence. And since these are SHOULDs and not MUSTs, I suppose there are valid reasons to violate them. Can you give some idea of what those reasons might be?

Section 7, definitions of BT, Block Length, and SSRC, and Section 8, SSRC: The SHALLs in there are silly. Why not just use "is"? Who would think to violate these so-called "requirements"?

Section 7 and 8, Packet Presented NTP timestamp: "If this field is empty, then it SHALL be set to 0..." I don't understand what that means. Are you simply saying: "If this field is set to 0, it means that no Packet Presented NTP timestamp is available"? I don't get it.

Section 9:

   Applications performing IDMS may or may not be able to choose a
   synchronization method for the system clock, because this may be a
   system-wide setting which the application cannot change.

I agree, and it makes me wonder why the protocol is dependent on a wallclock instead of doing a relative-from-MSAS kind of scheme.

I agree that definition of "recently received RTP packet" needs to be tightened up.