I am the assigned Gen-ART reviewer for draft-ietf-avt-rtp-cnames-02.txt For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is almost ready for publication as a Proposed Standard but has some issues that need to be addressed. Major ===== * Section 4.2 * I think the recommendations for using an IPv6 address as a CNAME are not * sufficient. While I understand the authors' intent, the text in this section * does not talk about the scope of the IPv6 addresses and hence does not * provide the required effect. Specifically, an IPv6 link-local address would * not fit the profile for providing uniqueness across the Internet. Suggest rewording "To produce a short-term persistent RTCP CNAME, an endpoint that has one or more IPv6 addresses MUST use one of those IPv6 address(es) as the "host" part of its RTCP CNAME, regardless of whether that IPv6 interface is being used for RTP communication or not." to "To produce a short-term persistent RTCP CNAME, an endpoint that has one or more IPv6 addresses of non-link-local scope MUST use one of those IPv6 address(es) as the "host" part of its RTCP CNAME, regardless of whether that IPv6 interface is being used for RTP communication or not. Specifically, the endpoint MUST NOT use a link-local scope address as the "host" part of its RTP CNAME" * It is unclear if the CNAME will stop being used if an IPv6 address becomes invalid (i.e. the valid lifetime expires) and is no longer assigned to an interface on the device. Can you please clarify? * Section 5 * The use of privacy addresses (RFC4941) will ensure that the CNAME will change periodically (once a day by default) and hence will guard against long term correlation. I think this is worthwhile mentioning it here. Minor ===== * Section 4.2 * The textual representation of an IPv6 address can be 39 octets long. I am not sure where the 24 octets number came from. Suggest replacing "The IPv6 address is converted to its textual representation [RFC5952], resulting in a printable string representation as short as 3 octets and as long as 24 octets" with "The IPv6 address is converted to its textual representation [RFC5952], resulting in a printable string representation as short as 3 octets and as long as 39 octets" I think the realization of HMAC with SHA-1 as the hash algorithm should be denoted by the term HMAC-SHA1, and not SHA1-HMAC as stated in the draft. Also, it is possible to include the truncation criteria in this term as well. i.e. HMAC-SHA1-96 will fully specify the algorithm and the truncated output length.