Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09

"Romascanu, Dan (Dan)" <> Mon, 10 June 2013 14:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0C3E21F938E; Mon, 10 Jun 2013 07:40:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.348
X-Spam-Status: No, score=-103.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N1TuFurvVW-D; Mon, 10 Jun 2013 07:40:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3239421F9399; Mon, 10 Jun 2013 07:40:26 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.87,837,1363147200"; d="scan'208,217"; a="12522144"
Received: from unknown (HELO ([]) by with ESMTP; 10 Jun 2013 10:40:24 -0400
Received: from unknown (HELO ([]) by with ESMTP; 10 Jun 2013 10:35:37 -0400
Received: from ([fe80::6db7:b0af:8480:c126]) by ([]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 10:40:22 -0400
From: "Romascanu, Dan (Dan)" <>
To: Kevin Gross <>, "Brandenburg, R. (Ray) van" <>
Thread-Topic: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09
Thread-Index: AQHOZeZ7ymQ4hhifMECwBepzBAET3ZkvBFkQ
Date: Mon, 10 Jun 2013 14:40:22 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA199E5BAZFFEXMB04globala_"
MIME-Version: 1.0
Cc: General Area Review Team <>, "" <>, "" <>
Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Jun 2013 14:40:33 -0000

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.



From: [] 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;;
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
Media Network Consultant
AVA Networks -<>,<>

On Mon, Jun 10, 2013 at 2:33 AM, Brandenburg, R. (Ray) van <<>> wrote:

-----Original Message-----
From: Romascanu, Dan (Dan) [<>]
Sent: zondag 9 juni 2013 9:53
To: General Area Review Team
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


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:


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.