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

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

  _______________________________________________
  Audio/Video Transport Working Group
  avt@ietf.org
  https://www.ietf.org/mailman/listinfo/avt