Dan, thanks for looking at this.

As a c= o-author, I'll weigh in on a couple of things that Ray did not address.=

Kevin Gross

+1-30= 3-447-0517

Media Network Consultant

AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

On Mon, Jun 10, 2013 at 2:33 AM, Branden= burg, R. (Ray) van <ray.vanbrandenburg@tno.nl> wrote= :

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dr= omasca@avaya.com]
Sent: zondag 9 juni 2013 9:53
To: General Area Review Team
Cc: draft-iet= f-avtcore-idms.all@tools.ietf.org
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-AR= T, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&= gt;.

Please resolve these comments along with any other Last Call comments you m= ay 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:

=A0 =A0Because RTP
=A0 =A0timestamps do wrap around, the sender of this packet SHOULD use
=A0 =A0recent values, i.e. choose NTP timestamps that reflect current time<= br> =A0 =A0and 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 ro= llover conditions both for the RTP timestamp (which can rollover a couple t= imes a day) and the NTP timestamp (which will have its first rollover in 20= 36). 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 computati= on 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:

=A0 =A0This SHOULD relate to the first
=A0 =A0arriving RTP packet containing this particular RTP timestamp, in cas= e
=A0 =A0multiple 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 a= nd 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 i= ndicating 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 no= t 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 ti= mes is not so critical in IDMS as arrival time allows a less precise synchr= onization than presentation times.

--bcaec50dc32c8bcb4004decd8f9c--