Hi Kevin, Thank you for looking at my comments and for explaining in detail the editorial decisions that you made. Both explanations make sense, and leaving the current text in place is acceptable.
Regards, Dan From: [email protected] [mailto:[email protected]] On Behalf Of Kevin Gross Sent: Monday, June 10, 2013 5:26 PM To: Brandenburg, R. (Ray) van Cc: Romascanu, Dan (Dan); General Area Review Team; [email protected]; [email protected] Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09 Dan, thanks for looking at this. As a co-author, I'll weigh in on a couple of things that Ray did not address. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org> On Mon, Jun 10, 2013 at 2:33 AM, Brandenburg, R. (Ray) van <[email protected]<mailto:[email protected]>> wrote: -----Original Message----- From: Romascanu, Dan (Dan) [mailto:[email protected]<mailto:[email protected]>] Sent: zondag 9 juni 2013 9:53 To: General Area Review Team Cc: [email protected]<mailto:[email protected]> Subject: Gen-ART review of draft-ietf-avtcore-idms-09 (resending, I mis-spelled .all address at the first try) I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-avtcore-idms-09 Reviewer: Dan Romascanu Review Date: 6/6/13 IETF LC End Date: 6/11/13 IESG Telechat date: Summary: Not Ready Major issues: 5. In Section 8: Because RTP timestamps do wrap around, the sender of this packet SHOULD use recent values, i.e. choose NTP timestamps that reflect current time and not too far in the future or in the past. Why a SHOULD here and not a MUST? If there are any cases of exception they need to be detailed. [Ray: I will check with my co-authors] [Kevin] Devices that receive these reports need to deal with rollover conditions both for the RTP timestamp (which can rollover a couple times a day) and the NTP timestamp (which will have its first rollover in 2036). I believe these requirements are already stated in RFC3550 and RFC5905 respectively. The suggestion to use recent timestamps in reporting reduces statistical chance that a receiving device will need to do extra computation required to handle an RTP rollover. There's no way to eliminate this possibility altogether and the requirement is stated in a qualitative way and so could not be enforced as a MUST. 6. In Section 8: This SHOULD relate to the first arriving RTP packet containing this particular RTP timestamp, in case multiple RTP packets contain the same RTP timestamp. Why a SHOULD here and not a MUST? If there are any cases of exception they need to be detailed. [Ray: I will check with my co-authors] [Kevin] This is an issue that the authors discussed at length and for which we do not believe there is an optimal solution and so we were reluctant to require our recommendation. Ideally we want an NTP timestamp indicating when all data required to render the specified RTP timestamp has arrived. For this we'd really like to know when the last packet for an RTP timestamp arrived. In the presence packet loss and reordering, it is not possible to reliably record the last packet. It is possible to record the first packet and so this is our recommendation. The accuracy of arrival times is not so critical in IDMS as arrival time allows a less precise synchronization than presentation times.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
