Re: [AVT] FW: New Version Notification for draft-begen-avt-rtp-cnames-01

Roni Even <Even.roni@huawei.com> Thu, 20 May 2010 07:07 UTC

Return-Path: <Even.roni@huawei.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 2D3113A6B27 for <avt@core3.amsl.com>; Thu, 20 May 2010 00:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.135
X-Spam-Level:
X-Spam-Status: No, score=-0.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_50=0.001]
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 HOOpBu0cUXzK for <avt@core3.amsl.com>; Thu, 20 May 2010 00:07:47 -0700 (PDT)
Received: from szxga05-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0C8153A6B12 for <avt@ietf.org>; Thu, 20 May 2010 00:07:47 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2P00C41IGRMX@szxga05-in.huawei.com> for avt@ietf.org; Thu, 20 May 2010 15:07:39 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2P0075ZIGROG@szxga05-in.huawei.com> for avt@ietf.org; Thu, 20 May 2010 15:07:39 +0800 (CST)
Received: from windows8d787f9 (bzq-79-177-43-153.red.bezeqint.net [79.177.43.153]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2P008EJIGHAF@szxml02-in.huawei.com>; Thu, 20 May 2010 15:07:39 +0800 (CST)
Date: Thu, 20 May 2010 10:05:46 +0300
From: Roni Even <Even.roni@huawei.com>
In-reply-to: <046601caf6e7$633c3990$c4f0200a@cisco.com>
To: 'Dan Wing' <dwing@cisco.com>, "'Ali C. Begen (abegen)'" <abegen@cisco.com>, avt@ietf.org
Message-id: <01fc01caf7ea$ebdcbb40$c39631c0$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-us
Content-transfer-encoding: 7bit
Thread-index: AcrsX4HHCnbPB7dpQ0+55RZub3M3ZgAAGcuQAqCX8hAAQSpLcA==
References: <04CAD96D4C5A3D48B1919248A8FE0D540C044FF3@xmb-sjc-215.amer.cisco.com> <046601caf6e7$633c3990$c4f0200a@cisco.com>
Cc: draft-begen-avt-rtp-cnames@tools.ietf.org
Subject: Re: [AVT] FW: New Version Notification for draft-begen-avt-rtp-cnames-01
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, 20 May 2010 07:07:48 -0000

Hi,

> 
> * Question: Are there any ideas on the table for generating a unique
> identifier that wouldn't be useful for traffic analysis?  That is, a
> unique
> identifier that is generated on each call?  For example, a BASE64-
> encoded
> SHA1-HMAC of one of the three pieces of information currently suggested
> in the
> memo (IPv6 address, unique FQDN, UUID), where the 'secret' is changed
> for
> every new RTP session?  This seems it could eliminate traffic analysis
> concerns.
> 

RFC 3550 says that one of the usage of RTCP is for monitoring and "To
facilitate third-party monitoring, the CNAME SHOULD be suitable for either a
program or a person to locate the source." 


Other comments

1. For the UUID I assume the proposal is to use the string representation of
the UUID maybe as a URN. 

2. As for the structure of CNAME, section 6.5.1 of RFC 3550 has the cname
composed of user and domain name. it also says that
"The user name SHOULD be in a form that a program such as "finger" or "talk"
could use, i.e., it typically is the login name rather than the personal
name.  The host name is not necessarily identical to the one in the
participant's electronic mail address. "
Maybe this document should recommend how to create a unique host part of the
CNAME and not the whole CNAME.

Regards
Roni Even