-----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 <[email protected]> > 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: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/gen-art
