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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
