Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Colin Perkins <csp@csperkins.org> Fri, 29 June 2012 12:18 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D92C21F869C for <avt@ietfa.amsl.com>; Fri, 29 Jun 2012 05:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 o108V75ryepK for <avt@ietfa.amsl.com>; Fri, 29 Jun 2012 05:18:20 -0700 (PDT)
Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id 93B4E21F86FD for <avt@ietf.org>; Fri, 29 Jun 2012 05:18:20 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Ska9T-0003RO-p8; Fri, 29 Jun 2012 12:18:19 +0000
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <4fde00ba.8854b40a.5854.12a4@mx.google.com>
Date: Fri, 29 Jun 2012 13:18:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <192F77F8-66E2-46B0-BE3C-F7B22CB72794@csperkins.org>
References: <4fde00ba.8854b40a.5854.12a4@mx.google.com>
To: Roni Even <ron.even.tlv@gmail.com>
X-Mailer: Apple Mail (2.1278)
Cc: draft-ietf-avtcore-idms@tools.ietf.org, avt@ietf.org
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2012 12:18:21 -0000

Roni,

I have some comments on this draft:

- I don't believe RTCP is on the RFC Editor's list of approved acronyms for document titles, but RTP is, so I suggest changing the title of the draft to "Inter-destination Media Synchronisation Using the RTP Control Protocol (RTCP)".

- Acronyms also need expanding on first use in the abstract.

- Editorial: the draft might read better if the Section 1.1 heading were removed, and if sub-sections 1.2, 1.3, and 1.4 were made part of a new Section 2 "Rationale".

- Editorial: in Section 1.2, "scalable to large multicast networks" may be better phrased "scalable to large groups" since the functionality is not multicast specific.

- Section 3, near the end of page 6, the draft says "...when both Alice and Bob received (or played out) a particular RTP packet". This might be clearer written "when both Alice and Bob received (and, optionally, when they played out) a particular RTP packet". 

- Section 3 doesn't seem to mention that Alice and Bob need synchronised clocks for this to work. It probably should.

- I find the justification for using a 32 bit NTP presentation timestamp in Section 6, but a 64 bit NTP presentation timestamp in Section 7 to be unconvincing. Could you either strengthen the justification, or move to a common size?

- Section 6: is the PT field needed? The combination of RTP timestamp and SSRC should identify a packet, even with changes in PT and clock rate.

- Section 6, penultimate paragraph: "...in which a certain RTP timestamp shows up for the first time" is problematic, since the RTP timestamp can wrap. 

- Section 8: "receiver involved need synchronised clocks" - yes, but be clear what clock needs to be synchronised. The RTP-format media clocks don't need to be synchronised, for example, while the NTP-format clock does.

- Section 8, 3rd paragraph: is the use of the mechanism in draft-williams-avtcore-clksrc mandatory? It would be useful to make an RFC 2119 style recommendation here.

- Section 8, last paragraph: should "...is therefore recommended to take the guidelines..." be "...RECOMMENDED..."?

Colin





On 17 Jun 2012, at 17:04, Roni Even wrote:
> Hi,
> I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for inter-destination media synchronization.
>  
> The WGLC will end on July 10th, 2012
>  
> Please review the draft and send comments to the list.
>  
> For the draft authors;  Are you aware of any IPR that applies to draft-ietf-avtcore-idms-05? If so,
> has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> The above question is needed for the document write-up when sent to publication.
>  
> Thanks
>  
> Roni Even
> AVTcore  co-chair
>  
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/