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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf