[Gen-art] Gen-ART Last Call review of draft-ietf-avt-rtp-cnames-02.txt

[Suresh Krishnan <[e-mail]>]

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

Thanks
Suresh