Re: [MMUSIC] late dtls-id request

"Paul E. Jones" <paulej@packetizer.com> Fri, 10 March 2017 04:07 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1881295B9 for <mmusic@ietfa.amsl.com>; Thu, 9 Mar 2017 20:07:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SWmYe_EmZXW for <mmusic@ietfa.amsl.com>; Thu, 9 Mar 2017 20:07:41 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF4B1295B7 for <mmusic@ietf.org>; Thu, 9 Mar 2017 20:07:40 -0800 (PST)
Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id v2A47bgp026708 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Mar 2017 23:07:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1489118858; bh=J/1ICB70gX+QoD6uS3uHt5dEnpjTCAcN+8tEzfsZgaQ=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=XxuoG9GOQCaO5jt6cxvGw5POAAEcykbGHZOvTZLmHUxNnLTtgEzra8qFngdAX55Pg dPfb3ILzj6aNnwuKcbjSd7AUAnBT1GlEXfsQ/KBl87ObBZRbE/xWZFjM95pfWvAHGn IcQODZ8S+DmZQQaDcym7t+Dn92q2W/IyflH1/gns=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "Christer Holmberg" <christer.holmberg@ericsson.com>, "Martin Thomson" <martin.thomson@gmail.com>
Date: Fri, 10 Mar 2017 04:07:37 +0000
Message-Id: <em430a9a48-ae49-4f39-810d-a40bc0947f91@sydney>
In-Reply-To: <D4E719EA.19139%christer.holmberg@ericsson.com>
References: <CABkgnnWz52xL2AzZ1j-GLhKd4+xHJD+zng-2AvhT95Dr1Djkug@mail.gmail.com> <D4E6C3C6.19093%christer.holmberg@ericsson.com> <D4E6C8D1.19099%christer.holmberg@ericsson.com> <CABkgnnV+83z1W=8zDoxoxfX1RcQ_z1-9SbQqyT2rNrTNsKOp4w@mail.gmail.com> <D4E719EA.19139%christer.holmberg@ericsson.com>
User-Agent: eM_Client/7.0.28492.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 09 Mar 2017 23:07:38 -0500 (EST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/869vwWC-uFfPq-TViTmL00TF9t0>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] late dtls-id request
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2017 04:07:42 -0000

Christer,

>>FWIW, I would be happier if you moved the 32 bit requirement to 120
>>and raised the minimum to 20, but that's a much bigger change.
>
>If people think such change would be useful I personally have no 
>problem
>implementing it.

Given there are uniqueness requirements for different applications (one 
I'm proposing is in PERC), more than 32 bits might be better.  We know 
SSRC collisions happen, so more randomness would likely help in many use 
cases.

Paul