Document: draft-ietf-avt-app-rtp-keepalive-05.txt
Reviewer: Sean Turner
Review Date: 19 May 2009
IETF LC End Date: 02 June 2009
IESG Telechat date: unknown

Summary: This draft has serious issues, described in the review, and needs to be rethought.

NOTE: If I'm off base on the BCP track comment, then I'd change my summary to: This draft is basically ready for publication, but has nits that should be fixed before publication.

ISSUES:

It's not clear to me why this ID is intended status is BCP.  What was the rationale for BCP?  According to RFC 2026, BCPs "standardize practices and the results of community deliberations" for common guidelines for policies and operations as well as the operation of the IETF itself.  RFC 2026 doesn't say that BCPs about protocols need to be in an RFC, but it seems odd to me that the protocol this ID recommends is in the RFC editor's queue.  To me, this ID reads like a requirements/rationale document for why draft-ietf-avt-rtp-and-rtcp-mux ought to be used over the other available mechanisms with some exceptions procedures.  Can this document be merged in to draft-ietf-avt-rtp-and-rtcp-mux as an appendix or should the intended status be different?

In each Section 4.* recommendation, RFC 2119 requirements terminology is used but the words are lower case and the words used don't match the requirements terminology used in Section 5.  For example, 4.1 says "should not" for "Transport Packet of 0-byte"
but section 5 says "NOT RECOMMENDED".  Was this done on purpose?  Can we delete the recommendation parts of Section 4.* (as they are really covered in Section 5), can we use different words in the recommendations paragraphs in 4.1 (e.g., ought instead of should), or can we use the same words in Section 4.* that are used in Section 5?

Section 7: 1st sentence: "An application supporting this specification must transmit either" or "An application supporting this specification MUST transmit either"?

NITS:

Section 1: r/their refreshment/keeping them refreshed

Section 4.1: r/(e.g.  UDP packet, DCCP packet ...)/(e.g.  UDP packet, DCCP packet).

Section 5: You offer explanations in Section 5 why to use or not use 4.1, 4.2, 4.3, 4.4, and 4.6 but curiously not 4.5.  Was this omitted for a reason?  Note: if the recommendations parts of 4.* are removed you need to add something about 4.5 in Section 5.

Section 6.1: r/does not allow to use different payloads within a same RTP session/Real-time text payload format [RFC4103] does not allow different payloads within the same RTP session