Subject: [Gen-art] Gen-ART review of draft-ietf-avt-app-rtp-keepalive-05.txt

From: Sean Turner <[email-masked]>
Date: Tue, 26 May 2009 18:23:05 -0400

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-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

spt