Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt

[Magnus Westerlund <[e-mail]>]

Hi,
(as individual)


I realize one part of my first issue was the question of how commonly
MAC addresses are going to be having the intended uniqueness properties.
This got a bit lost dealing with the equally important aspect that you
need to keep the one you have generated across any mobility event etc.

The comment from Steve Underwood, do raise this as being a genuine issue
in some cases. What I believe would be good, is to make it clear that an
implementation may have issues with using MAC address in certain types
of environments, like virtulazation. I think the simple fix is to press
that using a stored random value might have better properties.

Cheers

Magnus




On 2013-04-13 12:44, Ali C. Begen (abegen) wrote:
> I think we got all the essential WGLC comments addressed in this revision.
> If there is something we skipped, please let us know.
> 
> -acbegen
> 
> -----Original Message-----
> From: "[e-mail]" <[e-mail]>
> Date: Saturday, April 13, 2013 1:34 PM
> To: "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt
> 
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Audio/Video Transport Core Maintenance
>> Working Group of the IETF.
>>
>> 	Title           : Guidelines for Choosing RTP Control Protocol (RTCP)
>> Canonical Names (CNAMEs)
>> 	Author(s)       : Ali Begen
>>                          Colin Perkins
>>                          Dan Wing
>>                          Eric Rescorla
>> 	Filename        : draft-ietf-avtcore-6222bis-02.txt
>> 	Pages           : 10
>> 	Date            : 2013-04-13
>>
>> Abstract:
>>   The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
>>   persistent transport-level identifier for an RTP endpoint.  While the
>>   Synchronization Source (SSRC) identifier of an RTP endpoint may
>>   change if a collision is detected or when the RTP application is
>>   restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
>>   endpoints can be uniquely identified and associated with their RTP
>>   media streams.
>>
>>   For proper functionality, RTCP CNAMEs should be unique within the
>>   participants of an RTP session.  However, the existing guidelines for
>>   choosing the RTCP CNAME provided in the RTP standard are insufficient
>>   to achieve this uniqueness.  RFC 6222 was published to update those
>>   guidelines to allow endpoints to choose unique RTCP CNAMEs.
>>   Unfortunately, later investigations showed that some parts of the new
>>   algorithms were unnecessarily complicated and/or ineffective.  This
>>   document addresses these concerns and replaces RFC 6222.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-02
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-02
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt
>>
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------