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

["Brandenburg, R. (Ray) van" <[e-mail]>]

Hi Colin,

Thanks for your review. Sorry for not responding to you earlier. We took up your comments in the next iteration of the draft (which I will upload later today), but I forgot to respond to your comments personally. 

> - 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.

Thanks for these points. We have included all of them in the next iteration.

>- 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?

We will strengthen the justification. We had a lengthy discussion about this on the mailing list sometime ago, but I agree that the way it is written right now in the draft does not reflect the outcome of that discussion accurately. 

- 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.

The PT field is necessary in cases where the MSAS is not a receiver of the media stream. In order to do its job, it's necessary for the MSAS to have access to the 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.

Ok. We will fix this in the next iteration.

- 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.

True. Although I don't think it should be mandatory, and I think we should go with MAY.

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

Yes.

Best regards,

Ray

-----Original Message-----
From: Colin Perkins [mailto:[e-mail]] 
Sent: vrijdag 29 juni 2012 14:18
To: Roni Even
Cc: [e-mail]; [e-mail]
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

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 [e-mail] 
> https://www.ietf.org/mailman/listinfo/avt

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



This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer