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

From: [email-masked]
Date: Sat, 13 Apr 2013 03:34:55 -0700

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/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 13 Apr 2013 10:44:03 +0000

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: "[email-masked]" <[email-masked]>
Date: Saturday, April 13, 2013 1:34 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt

>_______________________________________________
>Audio/Video Transport Core Maintenance
>[email-masked]
>https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Roni Even" <[email-masked]>
Date: Sun, 14 Apr 2013 09:43:11 +0300

Hi Ali,
My comments are addressed in this version.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C.
Begen (abegen)
Sent: 13 April, 2013 1:44 PM
To: [email-masked]
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt

-acbegen

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Saturday, April 13, 2013 1:34 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt

>	Title           : Guidelines for Choosing RTP Control Protocol
(RTCP)
>Canonical Names (CNAMEs)

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 Apr 2013 11:54:40 +0200

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

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 22 Apr 2013 06:11:39 +0000

Hi Magnus,

I am not that knowledgeable about how the virtualization products deal
with their networking interfaces. While I am not comfortable to make a
generalization and somewhat blame such products for improper selection of
mac addresses, what about the following change?

After the following bullet in section 4.2:

To produce a short-term persistent RTCP CNAME, an RTP endpoint
      MUST either (a) use the numeric representation of the layer-2
      (Media Access Control (MAC)) address of the interface that is used
      to initiate the initial set of RTP sessions as the "host" part of
      its RTCP CNAME or (b) generate and use an identifier by following
      the procedure described in Section 5.  In either case, the
      procedure is performed once per initialization of the software.
      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), minimally the
      least significant 96 bits SHOULD be converted to ASCII using
      Base64 encoding [RFC4648] (to compromise between packet size and
      uniqueness - refer to Section 6.1).  If 96 bits are used, the
      resulting string will be 16 octets.

Add the following text?

"In some environments (for example, a virtualized operating system), the
MAC address may not be unique as expected. In these cases, using option
(b) above is RECOMMENDED."

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Apr 2013 09:02:43 +0200

> (b) above is RECOMMENDED."

Thanks, that is exactly what I wanted. Resolves my issue fully.

I hope others in the WG has input on this.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 22 Apr 2013 07:08:40 +0000

-----Original Message-----
From: Magnus Westerlund <[email-masked]>
Date: Monday, April 22, 2013 4:02 PM
To: "Ali C. Begen" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt

>Thanks, that is exactly what I wanted. Resolves my issue fully.

Cool, I will implement this change in a few days unless there are
objections and then maybe we can move forward?