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

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Suresh,

Thanks for the review.

> -----Original Message-----
> From: Suresh Krishnan [mailto:[e-mail]]
> Sent: Thursday, December 16, 2010 6:55 PM
> To: General Area Review Team; [e-mail]
> Subject: Gen-ART Last Call review of draft-ietf-avt-rtp-cnames-02.txt
> 
> 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?

We realized this and other issues with using ipv6 addresses, that part is now removed from the draft.
 
> 
> * 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.

It may or may not change AFAIK, but we could make a note of this. 
 
> 
> 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"

IPv6 text will be removed altogether.
 
> * 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.

Cool, thanks, will fix this.

Cheers, acbegen.
 
> Thanks
> Suresh
> 
> 
> 
> 
> 
> 
> 
> 
>