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 <m...@petit-huguenin.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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. > >> >> Jari >> >> On Nov 21, 2013, at 7:50 AM, Marc Petit-Huguenin <m...@petit-huguenin.org> >> wrote: >> >> 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 >>>>> >>>>> 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". >> >> 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: m...@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (GNU/Linux) > > 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 > -----END PGP SIGNATURE----- _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
