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

[Qin Wu <[e-mail]>]

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



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

Hopefully the next release will be more descriptive.

[Qin]: Great.
 
> > 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.

The details regarding UIUD are explained in its own draft. No need to repeat them here.
 
[Qin]: Okay,That's to say How to use SHA1-HMAC to generate CNAME is something new that is not explained its own draft.

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

Actually, the CNAME section in 3550 is consisting of guidelines. It does not mandate a particular method. Our draft will update that section.
 
[Qin]: Okay.

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

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

[Qin]: Okay.

Cheers, acbegen.

> 
> Cheers, acbegen.
> 
> >
> > Regards!
> > -Qin
> > ----- Original Message -----
> >
> > From: Roni Even <mailto:[e-mail]>
> > To: 'IETF AVT WG' <mailto:[e-mail]>
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
> >