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

[Suresh Krishnan <[e-mail]>]

Hi Ali,
   Thanks for the quick turnaround. I will look at the new revision when 
it comes out.

Cheers
Suresh

On 10-12-16 07:23 PM, Ali C. Begen (abegen) wrote:
> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>