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

["Ali C. Begen (abegen)" <[e-mail]>]

On Mar 8, 2013, at 3:19 AM, Kevin Gross <[e-mail]> wrote:

> That's technically sound. Editorially speaking, this new (b) method is already described in the third bullet point in section 4.2. Hopefully the authors can find a way to reference that instead of repeating it.
> 
Editorially, I like the straightforward version, if you don't mind.

> Separately, I note that section 5 allows you to create unique identifiers with more than 96 bits. I now don't see anywhere where you're allowed to use more than 96 bits so I question why we include that flexibility.

That part says "to compromise between packet size and uniqueness - refer to Section 6.1". So, I think if one does not care about the packet size, he can use longer bits.


> Kevin Gross
> [phone]
> Media Network Consultant
> AVA Networks - www.AVAnw.com, www.X192.org
> 
> 
> On Wed, Mar 6, 2013 at 9:03 PM, Ali C. Begen (abegen) <[e-mail]> wrote:
> Picking up this old thread.
> 
> On Jan 13, 2013, at 7:14 AM, Kevin Gross <[e-mail]> wrote:
> 
> > 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.
> >
> 
> What about this:
> 
> ... After obtaining an identifier in case of (a), the 48 bits are converted to the standard colon-separated hexadecimal format [RFC5342], e.g., "00:23:32:af:9b:aa", resulting in a 17-octet printable string representation. In case of (b), the least significant 96 bits are converted to ASCII using Base64 encoding [RFC4648], resulting in a 16-octet string representation.
> 
> -acbegen
> 
> > Kevin
> >
> > On Sat, Dec 29, 2012 at 2:48 PM, Ali C. Begen (abegen) <[e-mail]> wrote:
> > Kevin,
> >
> > -----Original Message-----
> > From: "Ali C. Begen" <[e-mail]>
> > Date: Monday, November 5, 2012 7:02 PM
> > To: Kevin Gross <[e-mail]>
> > Cc: "[e-mail]" <[e-mail]>
> > 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
> >
> >
> 
>