RTP Payload Format for H.264 Video
draft-ietf-avt-rtp-h264-11

[Ballot comment]
Reviewed by John Loughney, Gen-ART
His review:

Draft looks in good shape, no major nits.  The document is fairly dense, especially for a non-payload guy, but this seems like a reasonable specification.

[Ballot comment]
*** matchref -- match citations and references.
    Input file: draft-ietf-avt-rtp-h264-11.txt

!! Missing citation for Informative reference:
  P073 L038:    [11] P. Borgwardt, "Handling Interlaced Video in H.26L", VCEG-

!! Missing citation for Normative reference:
  P073 L021:    [7]  ITU-T Recommendation T.35, "Procedure for the allocation of

[Ballot discuss]
In section 9, the term authenication is used multiple times.  I'm not
quite sure that it is intended for each use.  I think in many cases
data origin authentication and/or data integrity is closer to what is
desired.  I don't require that you use RFC 2828 terms, although I
think that would be However it is important that whatever terms you
use have clear unambiguous meaning.  That is not currently true.

[Ballot comment]
I agree with Allison's note in the MIME-type review request [1].  The change controller should be the IESG.  Please add an RFC Editor note to make this correction.

[1]
http://eikenes.alvestrand.no/pipermail/ietf-types/2004-December/000521.html

[Ballot discuss]
Section 9 says:
  >
  > Because the data compression used with this payload format is
  > applied end-to-end, encryption may be performed after compression
  > so there is no conflict between the two operations.
  >
  Performing compression after encryption will not results in any
  compression!  Please change this to: " ... if encryption is performed,
  it MUST be performed after compression."

Requested ietf-types review and Last Call at the same time (Ted told me this is fine for this one -
I asked over a phone call last week).  I will give some AD comments with the LC; I never learn :)