Hi Ali,
I have a few comments/questions related to the draft:
Comment 1: The abstract now has a sentence: "For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition experiences." Doesn't it go beyond "RTP (receivers)" and "acquisition" as you also define e.g. a TLV related to presentation time delay (sometimes the MC RTP delivered content may not even be displayed) and application delay. I have no problem with the definition of such fields, but IMO it makes sense to make this clear in the abstract.
Comment 2: Base Report
The only informational field here is "response". It is still not defined, but you refer to the response code in RAMS draft (e.g. "success", etc).
I guess it is not possible to signal to an RR which additional info to send, i.e which TLV fields to use…From that point of view, would it not make sense to have some basic information -now defined in some TLV fields in the base report- that is always present, to enhance interoperability. I know we need to find the right balance between useful information reporting , bandwidth efficiency, and receiver reporting capabilities.
Candidate fields that could be inside this fixed base report are:
-flag/field indicating whether the report refers to a normal acquisition (based on SFGMP) or rapid MC RTP acquisition (or rather the intention by the RR to perform a rapid acquisition) for instance by means of RAMS
-a response code which you have indeed defined and its interpretation should be dependent on the previously mentioned flag/field
-initial launched request (either 1st RAMS-R for rapid acquisition, either 1st IGMP-join in case of normal acquisition) to 1st received RTP packet (always a multicast packet for normal acquisition and "normally" a burst packet when a rapid acquisition process was involved) delta time
-application request to initial launched request (either 1st RAMS-R for rapid acquisition, either 1st IGMP-join in case of normal acquisition) delta time
For these last two fields, a value must be specified that would indicate that the field is not filled out (because the receiver client implementation may not support it).
There could still be other fields that apply to both acquisition processes and fit in the base report, but they should be application independent (e.g. delta to presentation time is clearly app dependent)
Regards
Tom