Re: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG document
"Ali C. Begen (abegen)" <abegen@cisco.com> Thu, 17 June 2010 04:22 UTC
Return-Path: <abegen@cisco.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EEF3A6938 for <avt@core3.amsl.com>; Wed, 16 Jun 2010 21:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.633
X-Spam-Level:
X-Spam-Status: No, score=-9.633 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtURJEvt16hY for <avt@core3.amsl.com>; Wed, 16 Jun 2010 21:22:33 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B83673A66B4 for <avt@ietf.org>; Wed, 16 Jun 2010 21:22:33 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAIs/GUyrR7Ht/2dsb2JhbACecnGlMpoGhRoEg1I
X-IronPort-AV: E=Sophos;i="4.53,429,1272844800"; d="scan'208";a="145787721"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 17 Jun 2010 04:22:38 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5H4Mct5029538; Thu, 17 Jun 2010 04:22:38 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jun 2010 21:22:38 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Jun 2010 21:22:04 -0700
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540C5EED38@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <013c01cb0dbd$651fe440$23548a0a@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG document
thread-index: AcsNvWtVxlftyclSQtqGEufSUy/6WgAFqrRw
References: <044001cb03f7$8ed1f140$ac75d3c0$%roni@huawei.com> <03b401cb0acf$83bed1e0$23548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540C5EDF65@xmb-sjc-215.amer.cisco.com> <013c01cb0dbd$651fe440$23548a0a@china.huawei.com>
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>
X-OriginalArrivalTime: 17 Jun 2010 04:22:38.0698 (UTC) FILETIME=[B854BCA0:01CB0DD4]
Subject: Re: [AVT] accepting draft-begen-avt-rtp-cnames-02 as a WG document
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jun 2010 04:22:36 -0000
> -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > 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)" <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. Hopefully the next release will be more descriptive. > > 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. > > 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. > > 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. Cheers, acbegen. > > 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 > >
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Qin Wu
- [AVT] accepting draft-begen-avt-rtp-cnames-02 as … Roni Even
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Van Caenegem, Tom (Tom)
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Stephan Wenger
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Jean-Francois Mule
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Bill Ver Steeg (versteb)
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Peter Musgrave
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Ingemar Johansson S
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Peilin YANG
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Ali C. Begen (abegen)
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Michael Lague (mlague)
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Qin Wu
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Ali C. Begen (abegen)
- Re: [AVT] accepting draft-begen-avt-rtp-cnames-02… Qin Wu