Gen-ART LC review of draft-ietf-avt-rtcp-non-compound-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]