Re: [apps-discuss] AppsDir review of draft-ietf-avtcore-idms-09

Martin Thomson <martin.thomson@gmail.com> Thu, 11 July 2013 20:54 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356A621F9E24; Thu, 11 Jul 2013 13:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.485
X-Spam-Level: *
X-Spam-Status: No, score=1.485 tagged_above=-999 required=5 tests=[AWL=-3.891, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xZODkDbMQ-f; Thu, 11 Jul 2013 13:54:22 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 837B721F9D52; Thu, 11 Jul 2013 13:54:21 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id k10so13126015wiv.1 for <multiple recipients>; Thu, 11 Jul 2013 13:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QSGMr0zicqCqvi5yCbjra3aDrpx7K9ZELC2OPf7cDXM=; b=nNTZFtrMpZrrrfgGf3NfR2N4c6pTJhRksffPzd/XcVfy131P0gPyLE/qp1KkvKPvxy 0XKUWgtEvGbtgOeSXKde6YKYFjx1o/zKXeCfEvmSwuXLbT4JdMwqQnjFNsP3hI3Mp/D8 P03AZpjBxv2R72Cm2qqbWybLlaJa+hAyB/V6yYGkzugNmRLVJTizUw9O0tfhAtalurz8 3SpCk+QS7GhNmmA23S/P/vElk12DI2wjQJXle1p+CDgEJ7iWJMBj/NzPYcBBYk1zMD9M euYmdOXTvS5lrqEzat51MVdNdiMGo4NikBsd1Db7fmwzUbEUZyGfTvuaxdmpOgE9xp/D D+AQ==
MIME-Version: 1.0
X-Received: by 10.180.187.235 with SMTP id fv11mr20899424wic.65.1373576060605; Thu, 11 Jul 2013 13:54:20 -0700 (PDT)
Received: by 10.194.60.46 with HTTP; Thu, 11 Jul 2013 13:54:20 -0700 (PDT)
In-Reply-To: <7F110B3ECC623C4EADDEB82154F2693D12871300@EXC-MBX01.tsn.tno.nl>
References: <CABkgnnUpz=nxTjwFfMNGPgn0B0NMi8Xo7zT62i6ZKw9PD4O1UQ@mail.gmail.com> <7F110B3ECC623C4EADDEB82154F2693D12871300@EXC-MBX01.tsn.tno.nl>
Date: Thu, 11 Jul 2013 13:54:20 -0700
Message-ID: <CABkgnnU33ZcNEM7D118zeHOTPdCeVhoaa-u2To-sue4_pox93A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Stokking, H.M. (Hans)" <hans.stokking@tno.nl>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: The IESG <iesg@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>, "draft-ietf-avtcore-idms.all@tools.ietf.org" <draft-ietf-avtcore-idms.all@tools.ietf.org>
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-avtcore-idms-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2013 20:54:23 -0000

Thanks.

I neglected to send this to a few other folks initially.

On 10 July 2013 00:51, Stokking, H.M. (Hans) <hans.stokking@tno.nl> wrote:
> Dear Martin,
>
> Ray is out-of-office at the moment, I'll discuss your comments with him when he gets back next week. We'll let you know how we expect to deal with your comments then.
>
> Best regards, Hans
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: maandag 8 juli 2013 19:38
> To: draft-ietf-avtcore-idms.all@tools.ietf.org
> Subject: AppsDir review of draft-ietf-avtcore-idms-09
>
> I have been selected as the Applications Area Directorate (appsdir) reviewer for this draft.  (For background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
>
> Please resolve these comments along with any other Last Call comments you may receive.  Please wait for direction from your document shepherd or AD before posting a new version of the draft.
>
>
> Document: draft-ietf-avtcore-idms-09
> Reviewer: Martin Thomson
> Review Date: 2013-07-08
> IETF Last Call Date: ?
> IESG Telechat Date: ?
>
> Summary: This document is almost ready for publication as proposed standard.  There are a few minor issues.
>
>
> Section 6.
> Is there a strong reason for the MSAS to be placed at the RTP sender?
> Based on the description provided, this function can be independent, with the exception that it be necessary to receive RTCP reports.  The description in 6.1 omits the information that would be necessary to conclude that it is in the right place (i.e., it receives RTCP IDMS XR reports, and sends RTCP IDMS messages.)
>
> There is also a third potential role in this scenario, which is probably also assumed by an actual RTP sender.  In a network with large disparity of network delays and playback occurring on devices with limited capacity, is it not also possible - or even necessary - for an RTP sender to perform some buffering to add delay?
>
> Section 7 re: Synchronization Packet Sender Type .
>
> I'm not finding any motivation for the inclusion of this field and I can't infer from the text what its purpose is.  I think that the document needs something here.  I notice that removing it would allow you to remove 32-bits from the payload.
>
> Section 7 re: Packet Presented NTP timestamp: 32 bits.
>
> The description of this parameter requires special handling with respect to epoch and rollover.  I might assume that it is within 2^16 seconds of the received timestamp, but always greater.
>
> There are other ways to encode this information, though.  Since this is always strictly after a packet is received, then encoding a delta might also be possible.  That would set the epoch for this field to the packet received NTP timestamp and avoid any rollover issues (though it would limit the amount of buffering delay to 2^16).
>
> Section 11.
> This ABNF implies that the 'a' in 'a=rtcp-idms' is case-insensitive.
> This is not permitted by RFC 4566.
>
> Note that you should also specify 'decimal' rather than 'numerical' in the description, assuming of course that you want decimal numbers.
> This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer