Re: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG document

Hi, Ali:
Sorry for late feedback belows.
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "Qin Wu" <sunseawq@huawei.com>; "Roni Even" <Even.roni@huawei.com>; "IETF AVT WG" <avt@ietf.org>
Sent: Monday, June 14, 2010 2:43 AM
Subject: RE: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG document

Thanks for the review.

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin Wu
> Sent: Sunday, June 13, 2010 4:08 AM
> To: Roni Even; 'IETF AVT WG'
> Subject: Re: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG document
> 
> Hi,
> I read this draft and think it has addressed the key issue.
> However, there are some issues left I would like to discuss:
> 1) Section 4.1 proposes two kind of unique CNAME with different scopes, i.e, persistent CNAME with
> global scope, Per-Session CNAME with session scope,  Section 4.2 provide five technologies
> to generate unique CNAME, I am wondering in all these CNAMEs generated using the five technologies,
> which one is persistent CNAME, which one is Per-Session CNAME? How do you know the
> scope of CNAME?

If the endpoint is not using something from a given RTP session in generating its CNAME (i.e., all the input parameters are constant and are independent of the current RTP session), the resulting CNAME will be a persistent one.

[Qin]: Yes. So good if the text in the document can go into some more detail as you explained.

> 2) In section 4.2, it described:
> "
>       an endpoint MAY perform SHA1-HMAC [RFC2104] on the
>       concatenated values of the RTP endpoint's initial SSRC, the source
>      and destination IP addresses  and ports, and a randomly-generated value [RFC4086], and then
>       truncate the 160-bit output to 96 bits and finally convert the 96
>       bits to ASCII using Base64 encoding [RFC4648].  This results in a
>       128-bit printable CNAME.
> "
> I agree SHA1-HMAC can be used to generate Unique CNAME. But is it too strict to mandate how to
> generate CNAME using SHA-HMAC?

The sentence above is not mandating anything at all. It uses "MAY". 

[Qin]: My curiosity is Why you didn't give the details how to generate CNAME using UUID in the previous bullet while you give the detail how to generate CNAME using SHA1-HMAC.

> maybe you only need to mention that we can use SHA1-HMAC to generate CNAME and probably input could be
> something you mentioned in section 4.2. That's enough.
> The reason to say this is becos maybe there are some other ways to use SHA1-HMAC to generate CNAME.
> 3) In section 4.2, you only mentioned 5 techniques that can be used. But is there anything else you
> are missing? Is it mandatory to only use these five techniques? I am hard to believe this.

You are reading too much into the draft. It is a guidelines document. It lists several methods and says rtp endpoints SHOULD (not MUST) choose one of them. If you have other methods that you would like to propose, please do so.

[Qin]: Yes, but this guideline will be used to update RFC 3550 which is not a guideline. 
, And If I have methods, I will contribute as you suggested.:-)

> 4) In the first paragraph of section 4, using IPv4 address has its limitation and it is not easy to
> percieve NAT existing. I am wondering how is this paragraph related to the guideline described in
> section 4.2?

It basically tells you not to use your IPv4 address as the host part of your CNAME.

[Qin]: The problem is whether using IPv4 address or not mostly depends on the scenario you are focusing on (e.g., IPv4 scenario, IPv6 scenario, dual-stack scenario).
I can't believe you can use IPv6 address to generate CNAME instead of using IPv4 address in the pure IPv4 scenario. Am I right?

Cheers, acbegen.

> 
> Regards!
> -Qin
> ----- Original Message -----
> 
> From: Roni Even <mailto:Even.roni@huawei.com>
> To: 'IETF AVT WG' <mailto:avt@ietf.org>
> Sent: Friday, June 04, 2010 11:06 PM
> Subject: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG document
> 
> 
> Hi,
> 
> In Section 6.5.1 of RFC3550, there are a number of recommendations for choosing a unique RTCP
> CNAME for an RTP endpoint.  However, in  practice, some of these methods are not guaranteed to produce
> a  unique CNAME.
> http://tools.ietf.org/html/draft-begen-avt-rtp-cnames-02 proposes updated guidelines for
> choosing CNAMEs, superseding those presented in Section 6.5.1 of [RFC3550].
> 
> This was recognized as an issue to solve in the last IETF meetings.
> 
> The AVT chairs would like to ask if the group feels that this document should be accepted as a
> starting point for the working group document for resolving the issue.
> 
> Please send any comments till June 12th
> 
> Thanks
> Roni Even
> AVT co-chair
> 
> 
> 
> 
> 
> 
> ________________________________
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> 