Hi Suresh, Thanks for the review.
> -----Original Message----- > From: Suresh Krishnan [mailto:[email protected]] > Sent: Thursday, December 16, 2010 6:55 PM > To: General Area Review Team; [email protected] > 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 > > > > > > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
