Hi Thanks for the comments, I will fix this later on as I get more comments. As regards to the minor issue in 4.2.1. I am not sure here, I would say that it is important to stress that an application must verify that delivery of reduced-size RTCP is successful. I would personally prefer a MUST here. Regards Ingemar > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@xxxxxxxxxxxxxxxxx] > Sent: den 9 februari 2009 21:21 > To: Magnus Westerlund; Ingemar Johansson S > Cc: ietf@xxxxxxxx; General Area Review Team > Subject: Gen-ART LC review of draft-ietf-avt-rtcp-non-compound-08 > > I have been selected as the General Area Review Team > (Gen-ART) reviewer for this draft (for background on Gen-ART, > please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > Please resolve these comments along with any other Last Call > comments you may receive. > > Document: draft-ietf-avt-rtcp-non-compound-08 > Reviewer: Spencer Dawkins > Review Date: 2009-02-09 > IETF LC End Date: 2009-02-09 > IESG Telechat date: (not known) > > Summary: This document is almost ready for publication as a > Proposed Standard. I have one minor comment and a few nits, > reported below. > > Major issues: None noted. > > Minor issues: > > 4.2.1. Verification of Delivery > > o An algorithm to detect consistent failure of delivery > of reduced- > size RTCP MUST be used by any application using it. The details > of this algorithm are application dependent and > therefore outside > the scope of this document. > > Spencer (minor): does it make sense to have a MUST for > something that's out of scope for this document, with no > reference to any other document? > > Nits/editorial comments: > > > 1. Introduction > > There are a number of benefits with reduced-size RTCP, these are > discussed in Section 3.3. > > Spencer (nit): s/RTCP,/RTCP;/ > > 3.4.5. Header Compression > > Two issues are related to header compression, possible changes are > left for future work: > > Spencer (nit): s/, possible/. Possible/ > > 4.2.1. Verification of Delivery > > o The middle box issue is more difficult and here one will be > required to use heuristics to determine if the reduced-size RTCP > are delivered or not. The methods detect successful delivery of > reduced-size RTCP packets depends on the packet type. The RTCP > > Spencer (nit):s/methods detect/method used to detect/ (note > that there are missing words AND a numbering mismatch in this > sentence). > > packet types for which successful delivery can be detected are: > > 6. Security Considerations > > The security considerations of RTP [RFC3550] and AVPF > [RFC4585] will > apply also to reduced-size RTCP. The reduction in validation > strength for received packets on the RTCP port may result > in a higher > degree of acceptance of spurious data as real RTCP. This > vulnerability can mostly be addressed by usage of any security > mechanism that provide authentication, one example such > mechanism is > SRTP [RFC3711]. > > Spencer (nit): s/authentication, one example > such/authentication; one such/ > > > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf