Subject: [Gen-art] Gen-ART Review of draft-ietf-avtext-multiple-clock-rates-10

From: Wassim Haddad <[email-masked]>
Date: Wed, 20 Nov 2013 23:50:45 +0100

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document: draft-ietf-avtext-multiple-clock-rates-10
Reviewer:  Wassim Haddad
Review Date: 20 Nov 2013
IETF LC End Date: 22 Oct 2013
IETF Telechat Date: 21 Nov 2013

Summary:  This draft is almost ready for publication as proposed standard

- Major Issues: None

- Minor Issues: 

-> In the introduction section, I suggest re-wording the following (long and not so clear) sentence:

"Schulzrinne, et al. [RFC3550] lists using multiple clock rates as one of the reasons to not use different payloads on the same SSRC but unfortunately this advice has not always been followed and some RTP implementations change the payload in the same SSRC even if the different payloads use different clock rates".

-> Please consider adding the following to the terminology section:  
- SSRC,
- Lip,
- SR

Regards,

Wassim H.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 21 Nov 2013 03:50:03 -0700

Hi Wassim,

Thanks for the review.  Please see my answers below.

On 11/20/2013 03:50 PM, Wassim Haddad wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> 
> Document: draft-ietf-avtext-multiple-clock-rates-10 Reviewer:  Wassim
> Haddad Review Date: 20 Nov 2013 IETF LC End Date: 22 Oct 2013 IETF Telechat
> Date: 21 Nov 2013
> 
> "Schulzrinne, et al. [RFC3550] lists using multiple clock rates as one of
> the reasons to not use different payloads on the same SSRC but
> unfortunately this advice has not always been followed and some RTP
> implementations change the payload in the same SSRC even if the different
> payloads use different clock rates".

Do you have a suggestion to make this sentence better?

> 
> -> Please consider adding the following to the terminology section: -
> SSRC, - Lip, - SR

SSRC and SR (and RR) are already scheduled for expansion in the next version
but I do not think they require an entry in the terminology section, as they
are already defined in RFC 3550.  On the other hand I an not sure why you want
a definition for "Lip" as it is used in the text in its dictionary sense (RFC
3550 does not define lip either).

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Nov 2013 08:51:32 -0300

Many thanks for this review, Wassim! I have balloted a no-obj position for this draft for today's IESG telechat. Marc: I assume you have the token on ensuring a resolution for the points is reached somehow.

Jari

On Nov 21, 2013, at 7:50 AM, Marc Petit-Huguenin <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi Wassim,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJSjeVWAAoJECnERZXWan7EAaoQAMpSUp2bgsaN5cY3+rNUdo0o
> b0eJ3q8o4XxeArVhsZfMY0TVx7lOoJM4awaI92srNW232dK7rso26JmiV1gHOlrp
> UJawe3P/Hoy+bjPQLjGqVYWKmbZnjPtMVFvVJ3QZvXUe2/GljoJnJigm74t2VLv5
> RKjg1DDbekUVyutCo3Ym5vqDHErCIkFvMmIeNf9wQ8P3H3leH6WVbs2wIHIGG/WP
> UqwOroLORdvo9ymTgeP1uC+beLSGBjTAJsmb83ZM0fMzdcHwHiTAXIWzEM4yHey6
> b/cz+VPGMqO7bFdEqMuCFjUOhgncOpNnxJ9VSrYpzWy9qUyzq9xsHKJy0lONSayi
> REe5rygjyuGVIufMsOvVsGDuNUv4JoxUEZ6cTYFZ+uHIHfomxc0YCkF4CB7AWXjd
> tVd8nGXImEDH+krEJOBcjMZitNu4r2vZOEQH6NiA3lT2SXe1VvxFFhK1HxMdC3vj
> NSjdIV0IpkZXAPS7pXlkILxUY65qD8y1lqdkuLXInAIM2+3wHKtL5jhQbDyDnjjR
> C4FN3Y6nrAJflllO+9gBe3D/saYyRXHK7DaKy5UV1WZswenbOPBJXf2AmFLGXY0y
> H4gYRT4KHwBKT3VDKKszQe2l5ecjr6zUxyFAR5X7f1TmTHtds1oKAC0WiISSMgrq
> gxRiMhunciJ5WryCsY7v
> =YypU
> -----END PGP SIGNATURE-----
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 21 Nov 2013 06:51:20 -0700

On 11/21/2013 04:51 AM, Jari Arkko wrote:
> Many thanks for this review, Wassim! I have balloted a no-obj position for 
> this draft for today's IESG telechat. Marc: I assume you have the token on 
> ensuring a resolution for the points is reached somehow.

Yes, although I am not sure how to fix the first point below.  I would suggest
to let the RFC editor decide if the sentence really need improvement.

>>>>  Haddad Review Date: 20 Nov 2013 IETF LC End Date: 22 Oct 2013 IETF 
>>>> Telechat Date: 21 Nov 2013
>>>> 
>>>> "Schulzrinne, et al. [RFC3550] lists using multiple clock rates as
>>>> one of the reasons to not use different payloads on the same SSRC but
>>>>  implementations change the payload in the same SSRC even if the 
>>>> different payloads use different clock rates".
> 
> SSRC and SR (and RR) are already scheduled for expansion in the next
> version but I do not think they require an entry in the terminology
> section, as they are already defined in RFC 3550.  On the other hand I an
> not sure why you want a definition for "Lip" as it is used in the text in
> its dictionary sense (RFC 3550 does not define lip either).
> 

- -- 
Marc Petit-Huguenin

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Nov 2013 10:55:04 -0300

Ok. But I agree with Wassim that it needs breaking up. I'd just do s/but unfortunately/. Unfortunately/

Jari

On Nov 21, 2013, at 10:51 AM, Marc Petit-Huguenin <[email-masked]> wrote:

> iQIcBAEBCAAGBQJSjg/WAAoJECnERZXWan7E7m0P/1fuqPCj9a1uGafFzpwUCc7Y
> pv2wJEP1yXzTWa+cCBQRT3zCkIs5eO6Y68LDA4aQFT8DoF9xLpEWhjpo9HmRJhuK
> UUNtF0S6dUwgM+RQ3Ilhv7LcjsnFOiqxydRysd96glkNaMkVayj8uGlYgF0QBC5d
> lf8LZWq0+gC9xl1WKrH8tDRJGdeWSMOgaKLP/QCQcKxOJmFDem3EL2rD+qPcMX0k
> QITz8H0B2tu6v2mRvrEVj9PKPd7Rxpua1H6gc1Ngw2IOfAukNXU2SNQZDUlenmaV
> 9Eo+Ft1FBEWAA/oP6S5o/sUhXATdzyJ0ehgrgusAkuytllbMyrg0/7H4Se0o100O
> PqpZDMaU6R0UqlF2AE3Yq8HBbV0md4gPj9qUDz5xVln4yIUUA4K9s19i0op4gep6
> Mc7omNjtM3vDlqchbjpL5EZREhJfP8T/eLuW55duUeO1tQbBualnZ22lZtD0QVG7
> Q8NfI033mQCM4ugPV8wtwqQneYFx4AxmWKMS4m6nxOgy+irvcTrYcA9yfvT/GQsY
> jpyIVAHgBlkeNbmcxLouxXfeyJS2uGZFVGrKqN2brL934zrpNsNEkx+H/4Ad6PDC
> P4oBpgwA+9G8ihpwaQTb0iirlwMCskJZPbn9JyCVuziUoSHVbC2SOd1talFnwxt8
> 21LUVSP2ZbUx7cT2RA4T
> =6pt2

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 21 Nov 2013 06:57:06 -0700

> unfortunately/. Unfortunately/

OK, I added this to the list of edit for the next version (this week-end).

>>>> Many thanks for this review, Wassim! I have balloted a no-obj
>>>> position for this draft for today's IESG telechat. Marc: I assume you
>>>> have the token on ensuring a resolution for the points is reached
>>>> somehow.
> 
> Yes, although I am not sure how to fix the first point below.  I would
> suggest to let the RFC editor decide if the sentence really need
> improvement.
> 
>>>> 
>>>> Jari
>>>> 
>>>>>>> I am the assigned Gen-ART reviewer for this draft. For
>>>>>>> background on Gen-ART, please see the FAQ at 
>>>>>>> Document: draft-ietf-avtext-multiple-clock-rates-10 Reviewer:
>>>>>>> Wassim Haddad Review Date: 20 Nov 2013 IETF LC End Date: 22 Oct
>>>>>>> 2013 IETF Telechat Date: 21 Nov 2013
>>>>>>> 
>>>>>>> -> In the introduction section, I suggest re-wording the
>>>>>>> following (long and not so clear) sentence:
>>>>>>> 
>>>>>>> "Schulzrinne, et al. [RFC3550] lists using multiple clock rates
>>>>>>> as one of the reasons to not use different payloads on the same
>>>>>>> SSRC but unfortunately this advice has not always been followed
>>>>>>> and some RTP implementations change the payload in the same
>>>>>>> SSRC even if the different payloads use different clock
>>>>>>> rates".
>>>> 
>>>>>>> -> Please consider adding the following to the terminology
>>>>>>> section: - SSRC, - Lip, - SR
>>>> 
>>>> section, as they are already defined in RFC 3550.  On the other hand
>>>> I an not sure why you want a definition for "Lip" as it is used in
>>>> the text in its dictionary sense (RFC 3550 does not define lip
>>>> either).
>>>> 
> 
> 
> 

- -- 
Marc Petit-Huguenin