Draft:   draft-wing-behave-symmetric-rtprtcp-01.txt
Reviewer: Robert Sparks [rjsparks@nostrum.com]
Review Date:   2/19/2007 
IESG Telechat Date: 3/12/2007

Summary: This draft is basically ready for publication as an  
Informational RFC, but has nits that should be fixed before publication.

This draft formally establishes a definition of a term that's been  
used in informal conversations (lists, interop-events) for years.
While I don't think there was confusion in the community about these  
terms, there is certainly no harm in specifying them with clarity.
I don't know of a convenient larger draft to put these definitions in  
right now.

The draft is clearly written. The following nits are only suggestions  
- feel free to ignore them.

Paragraph 4 of the introduction feels confused. I suggest the  
following replacement text:
   There is no correspondence between the common local port and the  
common remote port.
    Device "A" might choose its common local transmit and receive  
port to be 1234. It's peer, device
    "B" is not constrained to also use port 1234. In fact, such a  
constraint would be impossible to
     meet since "B" might already be using that port for another  
application.

Last sentence of Section 3 (Recommended Usage) makes a very bold  
claim. I suggest changing it
to start "There are no known cases where"

In the security considerations section, you speak of complying with  
this specification, but this specification
only contains definitions. I suggest modifying the sentence to say  
"... if a host uses symmetric RTP or symmetric RTCP".

Tiny-nit: I think the idea in this draft can be understood without  
reading the RTP spec. You could leave all the references
as informational.