Port Mapping between Unicast and Multicast RTP Sessions
draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02

One comment from Ari Keränen who helped me with some of the reviews:

Section 7.2. says "The use of SDP for the port mapping solution normatively requires the support for [...] Multiplexing RTP and RTCP on a single port on both endpoints in the unicast session [RFC5761]".

Isn't this a requirement for the whole mechanism (if RTP and RTCP are used on the same ports as defined in section 3), not just with SDP? Perhaps the RFC5761 requirements should already be mentioned in section 3?

I don't object to this document being published, but I must say for someone outside of the area, this is rather dense and difficult to comprehend. In particular, getting through section 3 is nearly impossible without a lot of forward-reference looking. It took me reading through all of sections 4 and 5 to finally figure out (a) that the Token is simply a server-generated hash of the client's IP address, a time-to-live, and some random data generated by the client (section 3 says that "The Token is essentially an opaque encapsulation", and I have no idea what that is supposed to mean); and (b) that the client is told of the Token's expiration when it requests the Token. I would really like that first part of section 3 to lay out the basic principles in easier to understand language.

Please expand "SSM" on first use, and consider adding an informational reference to RFC 4607.

(1)  s/If there is no NAT devices/If there are no NAT devices/

(2) p20 says:  key-id || hash-alg (client-ip | nonce | abs-expiration) but since you're recommending HMAC-SHA1 that should be mac-alg rather than hash-alg.

(3) Since the client controls all the inputs to the recommended HMAC calculation, except the expiration time, which may be guessable, it really had better not be the case that that same secret key is used for something else that could get fooled if presented with a token. This is perhaps an unlikely cross-protocol attack (though with manual key management, perhaps not that unlikely) but I'd suggest a sentence in the security considerations saying servers MUST NOT use the same secret from the recommended scheme for other purposes.