I am the assigned Gen-ART reviewer for draft-wing-behave-symmetric-
rtprtcp-01.txt
For background on Gen-ART, please see the FAQ at <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.
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
