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

From: Roni Even <[email-masked]>
Date: Fri, 04 Jun 2010 18:06:38 +0300

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

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 4 Jun 2010 17:11:21 +0200

Roni,

I support this work,
Tom

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: vrijdag 4 juni 2010 17:07
To: 'IETF AVT WG'
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].

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.

Thanks

Roni Even

AVT co-chair

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 04 Jun 2010 08:19:12 -0700

Me as well.
Stephan

On 6.4.2010 08:11 , "Van Caenegem, Tom (Tom)"
<[email-masked]> wrote:

> choosing a unique RTCP CNAME for an RTP endpoint.  However, in  practice, some
> of these methods are not guaranteed to produce a  unique CNAME.
> 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.
>  
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Jean-Francois Mule <[email-masked]>
Date: Fri, 4 Jun 2010 09:23:06 -0600

I also support this work.

Jean-Francois.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephan Wenger
Sent: Friday, June 04, 2010 9:19 AM
To: Van Caenegem, Tom (Tom); Roni Even; 'IETF AVT WG'
Subject: Re: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG document

Me as well.
Stephan

On 6.4.2010 08:11 , "Van Caenegem, Tom (Tom)" <[email-masked]> wrote:
Roni,

I support this work,
Tom

Hi,

Thanks
Roni Even
AVT co-chair

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 4 Jun 2010 10:26:55 -0500

Bill VerSteeg

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jean-Francois Mule
Sent: Friday, June 04, 2010 11:23 AM
To: Stephan Wenger; Van Caenegem, Tom (Tom); Roni Even; 'IETF AVT WG'
Subject: Re: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG
document

Jean-Francois.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephan Wenger
Sent: Friday, June 04, 2010 9:19 AM
To: Van Caenegem, Tom (Tom); Roni Even; 'IETF AVT WG'
Subject: Re: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG
document

Me as well.
Stephan

Roni,

I support this work,
Tom

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: vrijdag 4 juni 2010 17:07
To: 'IETF AVT WG'
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].

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.

Thanks
Roni Even
AVT co-chair

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 4 Jun 2010 13:02:38 -0400

+1

---

From: Peilin YANG <[email-masked]>
Date: Tue, 08 Jun 2010 16:01:53 +0800

Support.

Peilin

---

From: Qin Wu <[email-masked]>
Date: Sun, 13 Jun 2010 16:07:48 +0800

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?
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?
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.
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?

Regards!
-Qin
----- Original Message ----- 
  From: Roni Even 
  To: 'IETF AVT WG' 
  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 ThanksRoni EvenAVT co-chair   

------------------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 13 Jun 2010 11:43:29 -0700

Thanks for the review.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
> Sent: Sunday, June 13, 2010 4:08 AM
> To: Roni Even; 'IETF AVT WG'
> 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.

> generate CNAME using SHA-HMAC?

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

> 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.
> 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.

> 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.

Cheers, acbegen.

> 	From: Roni Even <mailto:[email-masked]>
> 	To: 'IETF AVT WG' <mailto:[email-masked]>
> 	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].
> 
> 	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.
>

---

From: "Michael Lague (mlague)" <[email-masked]>
Date: Tue, 15 Jun 2010 10:50:20 -0500

I support this work.

--Mike Lague

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Friday, June 04, 2010 11:07 AM
To: 'IETF AVT WG'
Subject: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG document

Hi,

 

Thanks
Roni Even
AVT co-chair

---

From: Qin Wu <[email-masked]>
Date: Thu, 17 Jun 2010 09:35:40 +0800

Hi, Ali:
Sorry for late feedback belows.
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Roni Even" <[email-masked]>; "IETF AVT WG" <[email-masked]>
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.

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

[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.

[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.:-)

[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.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 16 Jun 2010 21:22:04 -0700

> From: Qin Wu [mailto:[email-masked]]
> Sent: Wednesday, June 16, 2010 9:36 PM
> To: Ali C. Begen (abegen); Roni Even; IETF AVT WG
> 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.
> 

Hopefully the next release will be more descriptive.
 
> [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.

The details regarding UIUD are explained in its own draft. No need to repeat them here.
 
> 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.
> 

Actually, the CNAME section in 3550 is consisting of guidelines. It does not mandate a particular method. Our draft will update that section.
 
> [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).

If the endpoint does not have an IPv6 address, it clearly cannot generate a CNAME based on it.

Cheers, acbegen.

---

From: Qin Wu <[email-masked]>
Date: Thu, 17 Jun 2010 12:36:13 +0800

---- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Roni Even" <[email-masked]>; "IETF AVT WG" <[email-masked]>
Sent: Thursday, June 17, 2010 12:22 PM
Subject: RE: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG document

[Qin]: Great.

 
[Qin]: Okay,That's to say How to use SHA1-HMAC to generate CNAME is something new that is not explained its own draft.

 
[Qin]: Okay.

[Qin]: Okay.

Cheers, acbegen.