IETF Logo Mail Archive

Re: [AVTCORE] FW: New Version Notification fordraft-rescorla-avtcore-6222bis-00.txt

"Art Allison" <AAllison@nab.org> Tue, 15 January 2013 16:01 UTC

Return-Path: <aallison@nab.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDAD21F86B8 for <avt@ietfa.amsl.com>; Tue, 15 Jan 2013 08:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJ3IKD4FzaDn for <avt@ietfa.amsl.com>; Tue, 15 Jan 2013 08:01:05 -0800 (PST)
Received: from p01c11o145.mxlogic.net (p01c11o145.mxlogic.net [208.65.144.68]) by ietfa.amsl.com (Postfix) with ESMTP id B8FCF21F86A9 for <avt@ietf.org>; Tue, 15 Jan 2013 08:01:04 -0800 (PST)
Received: from unknown [208.97.234.91] (EHLO p01c11o145.mxlogic.net) by p01c11o145.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id 04d75f05.6676d940.143363.00-498.325161.p01c11o145.mxlogic.net (envelope-from <aallison@nab.org>); Tue, 15 Jan 2013 09:01:04 -0700 (MST)
X-MXL-Hash: 50f57d4004817f77-bfc0de9a70230327d5306aed299430f02803a2e4
Received: from unknown [208.97.234.91] (EHLO NABSREX027324.NAB.ORG) by p01c11o145.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id f3d75f05.0.143346.00-316.325113.p01c11o145.mxlogic.net (envelope-from <aallison@nab.org>); Tue, 15 Jan 2013 09:01:04 -0700 (MST)
X-MXL-Hash: 50f57d40624993dd-fdaf345cb845cc8c898feb9a915f18aa2f07d3d1
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDF339.7F550B53"
Date: Tue, 15 Jan 2013 11:00:53 -0500
Message-ID: <71C9EC0544D1F64D8B7D91EDCC6220200CFC68AF@NABSREX027324.NAB.ORG>
In-Reply-To: <CALw1_Q3sBkDeAQMd1MKV1rC4fK4nSAvd88WN_EJXMdh2tSO7UQ@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVTCORE] FW: New Version Notification fordraft-rescorla-avtcore-6222bis-00.txt
Thread-Index: Ac3xAYe/x5ZtND0VS4Ko7RpF0ytecACN7+mA
References: <C15918F2FCDA0243A7C919DA7C4BE994F67420@xmb-aln-x01.cisco.com><C15918F2FCDA0243A7C919DA7C4BE9940CDE16EA@xmb-aln-x01.cisco.com> <CALw1_Q3sBkDeAQMd1MKV1rC4fK4nSAvd88WN_EJXMdh2tSO7UQ@mail.gmail.com>
From: Art Allison <AAllison@nab.org>
To: Kevin Gross <kevin.gross@avanw.com>, "Ali C. Begen (abegen)" <abegen@cisco.com>
X-AnalysisOut: [v=2.0 cv=B98OJpRM c=1 sm=1 a=tFGTPFZixTZ3yCXJchW01Q==:17 a]
X-AnalysisOut: [=Pk55NjwedokA:10 a=BvPfnLs-15kA:10 a=BLceEmwcHowA:10 a=g0F]
X-AnalysisOut: [pLpFZAAAA:8 a=KAB1gtzPAU4A:10 a=48vgC7mUAAAA:8 a=8pif782wA]
X-AnalysisOut: [AAA:8 a=AUd_NHdVAAAA:8 a=ShlZpSYcAAAA:8 a=FfhnUEOnPYrh8KE-]
X-AnalysisOut: [5OQA:9 a=wPNLvfGTeEIA:10 a=8SgyfJxrfqYA:10 a=-9UqKSle32gA:]
X-AnalysisOut: [10 a=Qd0007q6B0YA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a]
X-AnalysisOut: [=WGSFIyGZyLkA:10 a=wS5KViLViSX9-SR1:21 a=GvUbZqUW9gwGGN3-:]
X-AnalysisOut: [21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=TI2ux-7Y9X99P_bDJZA]
X-AnalysisOut: [A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 ]
X-AnalysisOut: [a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=wa4O7Aiq1LrCOjU8:21 ]
X-AnalysisOut: [a=--PbSON-zHOzAYSl:21 a=cy0sq_VE6X_drJET:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <aallison@nab.org>
X-SOURCE-IP: [208.97.234.91]
Cc: avt@ietf.org
Subject: Re: [AVTCORE] FW: New Version Notification fordraft-rescorla-avtcore-6222bis-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 15 Jan 2013 16:01:07 -0000

I share Kevin's view.

 

Art Allison 
Senior Director Advanced Engineering, Technology 
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418
Fax  202 775 4981 
www.nab.org <blocked::http://www.nab.org>  
Advocacy  Education  Innovation 

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin Gross
Sent: Saturday, January 12, 2013 3:15 PM
To: Ali C. Begen (abegen)
Cc: avt@ietf.org
Subject: Re: [AVTCORE] FW: New Version Notification fordraft-rescorla-avtcore-6222bis-00.txt

 

Sorry for the delay responding. I do think otherwise. (a) is fine because OUI registration prevents collisions. (b) relies on statistics to prevent collisions. There's not enough entropy in 48-bit number to statistically prevent collisions in a larger population of participants. See http://en.wikipedia.org/wiki/Birthday_problem. 96-bits is where things are workable.

 

Kevin

 

On Sat, Dec 29, 2012 at 2:48 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:

Kevin,


-----Original Message-----
From: "Ali C. Begen" <abegen@cisco.com>
Date: Monday, November 5, 2012 7:02 PM
To: Kevin Gross <kevin.gross@avanw.com>
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] FW: New Version Notification for
draft-rescorla-avtcore-6222bis-00.txt

>>Second bullet point in section 4.2 Item (b): Proposes truncating our nice
>>96-bit random CNAME to 48 bits. I think we have an unacceptable
>>opportunity for duplication with this approach. This CNAME should
>>probably use RFC 4648 in which case these CNAMEs
>>take the same form as the per-session CNAMES but differ in the
>>requirement to create once at software initialization. Is it necessary
>>for the different types of CNAMEs to have different appearance?
>
>I don¹t think there is such a requirement and your suggestion makes sense.

Thinking more about this, I think the current text is good. Item (a) uses
48-bit MAC addresses. So, even if we use truncating in item (b), its
collision probability will not be any worse than item (a)'s. Note that
both item (a) and (b) use 17-octet string representation whereas the
per-session CNAME uses 16-octet string representation.

Let me know if you think otherwise.

-acbegen

v2.23.0 | Report a Bug | By Email