From mmusic-bounces@ietf.org Thu Dec 01 09:13:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpBm-00076w-KB; Thu, 01 Dec 2005 09:13:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpBi-00072m-Pu for mmusic@megatron.ietf.org; Thu, 01 Dec 2005 09:13:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24961 for ; Thu, 1 Dec 2005 09:12:43 -0500 (EST) Received: from smtp7.clb.oleane.net ([213.56.31.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpWC-0006yY-2V for mmusic@ietf.org; Thu, 01 Dec 2005 09:34:41 -0500 Received: from Pavillonquatre ([194.3.133.88]) (authenticated) by smtp7.clb.oleane.net with ESMTP id jB1ED6sk002514 for ; Thu, 1 Dec 2005 15:13:08 +0100 Message-Id: <200512011413.jB1ED6sk002514@smtp7.clb.oleane.net> From: "Chantal Ladouce" To: Date: Thu, 1 Dec 2005 15:12:36 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX2gUdp58fj/GNrRYCS/VgnHrxvFg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [MMUSIC] Wireless/WiFi Convergence Conference - Call for Papers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0853458106==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0853458106== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0129_01C5F689.A9750C60" This is a multi-part message in MIME format. ------=_NextPart_000_0129_01C5F689.A9750C60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Wireless/WiFi Convergence Conference will be held in Paris on May 16 to May 19, 2006 http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006cfp.htm It is still time to submit proposals. Organizers are looking for UMA papers. ------=_NextPart_000_0129_01C5F689.A9750C60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Wireless/WiFi Convergence = Conference will be held in Paris on May 16 to May 19, 2006

http://www.upperside.fr/wirelessconvergence2006/wwconvergence200= 6cfp.htm

It is still time to submit proposals. = Organizers are looking for UMA papers.

------=_NextPart_000_0129_01C5F689.A9750C60-- --===============0853458106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0853458106==-- From mmusic-bounces@ietf.org Thu Dec 01 15:51:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvOR-0000fn-0D; Thu, 01 Dec 2005 15:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNX-00009U-5a; Thu, 01 Dec 2005 15:50:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25923; Thu, 1 Dec 2005 15:49:18 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehvi1-00084X-NQ; Thu, 01 Dec 2005 16:11:18 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhvNS-0006cN-0o; Thu, 01 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Dec 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bfcp-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams Author(s) : G. Camarillo Filename : draft-ietf-mmusic-sdp-bfcp-03.txt Pages : 14 Date : 2005-12-1 This document specifies how to describe BFCP streams in SDP session descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and their answers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bfcp-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-bfcp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-bfcp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-1121731.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-bfcp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-bfcp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-1121731.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Fri Dec 02 12:00:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEH9-00042Y-Fo; Fri, 02 Dec 2005 12:00:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEH4-00041g-SU; Fri, 02 Dec 2005 12:00:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17035; Fri, 2 Dec 2005 11:59:56 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiEbn-0006EH-R1; Fri, 02 Dec 2005 12:22:07 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EiEH4-0001qk-6d; Fri, 02 Dec 2005 12:00:42 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 02 Dec 2005 12:00:42 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: 'Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)' to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org The IESG has received a request from the Multiparty Multimedia Session Control WG to consider the following document: - 'Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-16. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-comedia-tls-05.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 02 14:59:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiH3z-0007Ck-4K; Fri, 02 Dec 2005 14:59:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiH3x-0007CY-Jo; Fri, 02 Dec 2005 14:59:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07572; Fri, 2 Dec 2005 14:58:33 -0500 (EST) Received: from exchange4.oneonta.edu ([137.141.15.61] helo=EXCHANGEN4.oneonta.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiHOg-0004G0-9Z; Fri, 02 Dec 2005 15:20:47 -0500 Received: from mail pickup service by EXCHANGEN4.oneonta.edu with Microsoft SMTPSVC; Fri, 2 Dec 2005 14:59:19 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by batara.oneonta.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Dec 2005 12:15:14 -0500 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEH7-000424-4A; Fri, 02 Dec 2005 12:00:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEH4-00041g-SU; Fri, 02 Dec 2005 12:00:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17035; Fri, 2 Dec 2005 11:59:56 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiEbn-0006EH-R1; Fri, 02 Dec 2005 12:22:07 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EiEH4-0001qk-6d; Fri, 02 Dec 2005 12:00:42 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 02 Dec 2005 12:00:42 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 02 Dec 2005 17:15:15.0015 (UTC) FILETIME=[F5F3DD70:01C5F763] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: 'Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)' to Proposed Standard X-BeenThere: mmusic@ietf.org Reply-To: iesg@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org The IESG has received a request from the Multiparty Multimedia Session Control WG to consider the following document: - 'Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-16. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-comedia-tls-05.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 05 10:17:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjI5n-0007qE-6w; Mon, 05 Dec 2005 10:17:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjI5h-0007nn-5q; Mon, 05 Dec 2005 10:17:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01337; Mon, 5 Dec 2005 10:16:31 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjIQz-0005Js-V0; Mon, 05 Dec 2005 10:39:23 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 05 Dec 2005 07:17:02 -0800 X-IronPort-AV: i="3.99,217,1131350400"; d="scan'208"; a="373984109:sNHT1666046576" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB5FGaQc004612; Mon, 5 Dec 2005 07:17:00 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 10:16:21 -0500 Received: from [192.168.1.102] ([10.86.242.24]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 10:16:20 -0500 Message-ID: <439459C4.7000808@cisco.com> Date: Mon, 05 Dec 2005 10:16:20 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Midcom , Behave , IETF MMUSIC WG , IETF SIP List , IETF Sipping List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2005 15:16:20.0864 (UTC) FILETIME=[D8E81000:01C5F9AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Subject: [MMUSIC] Fora for TURN discussion: BEHAVE list X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Sorry for the broad distribution here, but I wanted to let folks know that I'm going to be moving discussions on TURN over to the behave list (http://www.ietf.org/html.charters/behave-charter.html). I'll be posting some issues shortly which require discussion, so if you are interested, please subscribe there. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 05 15:13:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjMiP-00056Q-BS; Mon, 05 Dec 2005 15:13:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjMiN-00055M-MH for mmusic@megatron.ietf.org; Mon, 05 Dec 2005 15:13:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05593 for ; Mon, 5 Dec 2005 15:12:44 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjN3i-0007Zp-H4 for mmusic@ietf.org; Mon, 05 Dec 2005 15:35:39 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 05 Dec 2005 12:13:24 -0800 X-IronPort-AV: i="3.99,217,1131350400"; d="scan'208"; a="681627392:sNHT31126028" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB5KD1BZ029319; Mon, 5 Dec 2005 12:13:22 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 12:13:01 -0800 Received: from [10.21.145.158] ([10.21.145.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 12:13:00 -0800 Message-ID: <439472CF.6040208@cisco.com> Date: Mon, 05 Dec 2005 12:03:11 -0500 From: Flemming Andreasen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [MMUSIC] Notes from side meeting on ICE, 2005-11-10 21.00-23.10 References: <50B1CBA96870A34799A506B2313F26670728A640@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670728A640@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2005 20:13:00.0937 (UTC) FILETIME=[4A93A790:01C5F9D8] X-Spam-Score: 0.7 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Elwell, John wrote: > The purpose was to resolve an issue with ICE version 06 whereby it > depended on reliable provisional responses (PRACK), which is not > widely implemented at present. > > Jonathan proposed a middle ground position. Subject to certain > conditions, as soon as a candidate has been validated successfully > (both ways), you can start sending media to that address, but must > send an updated offer at some stage. If PRACK is not available, you > have to wait for 200. > > Question over SRTP keying - uncertain whether any issues, e.g. to do > with windowing and different latencies on different candidates. May be > solved by different SSRCs with some implementations. This may occur > even if we do perform offer/answer exchange straight away. So there is > a general issue with SRTP, not introduced by ICE 06. Agreed to put > SRTP aside until sorted out RTP. > I'm not quite following the SRTP issue nor the part about using different SSRCs. Can you (or somebody else) elaborate on it ? -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 05 15:13:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjMiT-00058R-Pb; Mon, 05 Dec 2005 15:13:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjMiO-00055l-1x for mmusic@megatron.ietf.org; Mon, 05 Dec 2005 15:13:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05594 for ; Mon, 5 Dec 2005 15:12:44 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjN3i-0007Zq-W5 for mmusic@ietf.org; Mon, 05 Dec 2005 15:35:39 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 05 Dec 2005 12:13:25 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB5KCrAC008572; Mon, 5 Dec 2005 12:13:22 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 12:13:00 -0800 Received: from [10.21.145.158] ([10.21.145.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 12:12:59 -0800 Message-ID: <4394712D.1040605@cisco.com> Date: Mon, 05 Dec 2005 11:56:13 -0500 From: Flemming Andreasen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joerg Ott Subject: Re: Sharing ports between "m=" lines [Was Re: [MMUSIC] Re: Question on sdp-new} References: <200510131847.j9DIlNub002020@sj-core-1.cisco.com> <219F0A96-C91F-4279-B5F3-2C8B3A0F0F20@csperkins.org> <43569970.1080508@cisco.com> <438AB3EA.7040403@netlab.hut.fi> In-Reply-To: <438AB3EA.7040403@netlab.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2005 20:12:59.0843 (UTC) FILETIME=[49ECB930:01C5F9D8] X-Spam-Score: 0.7 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: 7bit Cc: "'Elwell, John'" , mmusic@ietf.org, Dan Wing , M.Handley@cs.ucl.ac.uk, Colin Perkins , van@packetdesign.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Joerg Ott wrote: > Flemming, > > sorry, I must have missed this thread earlier. > Let me briefly recap where this comes from: > > 1. This practice was originally documented in the SDP offer/anser > examples draft. The chairs felt that it was inappropriate to > document such behavior by example only and that some normative > language should be backing this since it was commonly felt a > useful thing to have. The result is in the SDP spec. There > was not much input though. > OK. Part of the input provided though raised some concerns with this. > 2. When RFC2327 was done, there was only a single RTP profile defined. > Some profiles allow mixing in a session but SDP does not allow that > to be specified. But we must also care of those applications that > do not use offer/answer. > > In principle, I am all in favor of solving this problem in a reasonable > way and I do not care that much which way it is. The present text in > SDP was meant to reflect observed behavior. This is why it is there. > The text itself was meant to be rather minimalistic, so it may well > have holes. If so (and what you sat clearly points into that > direction), we need to fix these (and of course your help is very > welcome here :-) > I'll be happy to help out. Can we start out by clarifying exactly what the scope of the problem we want to solve here is ? Once we agree on that we can then look at appropriate solutions. >> We've had the discussion around whether to allow port (i.e. transport >> address) reuse between multiple media lines a few times in the past >> (e.g. the thread "Multiple 'm' lines with the same port number" in >> 2003/04), and various concerns were expressed around that. To recap, >> the major concerns were: >> >> 1. Backwards compatibility issues with RFC 2327 implementations which >> did not specify this . > > > This was considered to be quite common practice and therefore > documented. > Common among some endpoints perhaps, however that does not make it generally backwards compatible. > Grouping of m= lines is not necessarily backwards compatible in that > sense either. Agreed - especially once you get outside of SIP where you don't necessarily have an option tag to ensure support. Regardless, use of an option tag here is not necessarily desirable (e.g. consider the well-known forking scenarios with one endpoint supporting it and another that does not) > But this calls > > (RFC2327 is fundamentally broken and did not specify much in the first > place -- and we notice the brittleness of SDP over and over again, > but this is a different story) > >> 2. Potential for multiplexing misuse when using different types of >> media streams on the same transport (e.g. audio and video) > > > The present SDP text is supposed to prevent this as you state below. > >> 3. Consistency with RFC 3264 offer/answer procedures. For example >> 3264 states >> >> If multiple media streams of the same type are present in an offer, >> it means that the offerer wishes to send (and/or receive) multiple >> streams of that type at the same time. >> Other 3264 concerns have to do with matching of media streams in an >> updated offer/answer exchage (3264, Section 8). > > > This is an important point and we have to take additional steps to > ensure that o/a works in a backward-compatible way (which applies to > the new grouping attributes that are popping up as well). > Agreed. We may want to be a bit more specific here as well. There is seamless backwards compatibility and there is backwards compatibility where you recognize that the other side did not support what you wanted and you need to take some kind of recovery action. >> 4. Generally getting into a gray area of what this means. For >> example, can we now negotiate media streams with asymmetric codecs >> (one "m=" marked "sendonly", another marked "recvonly") ? How do we >> deal with all the other potential parameters that may differ between >> the two "m=" lines (fmtp parameters, RTCP bandwidth, etc.) ? > > > The text should indeed be a bit more explicit here. > >> Taking a look at the concerns above, the added text does little to >> address any but the second one (and even there, it's not entirely >> clear what "compatible media" actually means, e.g. is T38 fax relay >> compatible with G.711 audio ?) In summary, I have serious concerns >> with the current text on this in sdp-new-25 and belive it should >> either be removed or reworked significantly. > > > If you remove it that does not solve anything for those endpoints _not_ > doing o/a. And it it was put in on purpose. This means that we will > have to rework the text to (and possibly parts of the overall approach) > to address this. > OK, so if I can rephrase here: The updated SDP specification needs to have a solution to this problem so all implementations claiming conformance with it will support it (i.e. cannot just be an extension) ? > Related to this is some discussion from the last IETF concerning > groupings that are felt useful but not yet addressed: > > -- alternative RTP profiles for joint use and/or for exclusive > use (picking one) > -- allowing multicast and unicast addresses to be specified as > alternatives (which ANAT does not allow for) > > There may be more but these are the ones that need solving. > OK. Again, can we write up a paragraph or two describing exactly what the scope of the problems we want to solve here are (for example, when we say alternative RTP profiles, do the two profiles in fact have to be different) ? -- Flemming > Any suggestions are surely welcome. > > Joerg > >> I do however support the general idea of trying to solve the problems >> that lead to the above text, but explicit signaling mechanisms (e.g. >> using grouping of media lines as Magnus suggested) and more extensive >> treatment of the issues above is needed for this IMO. If there is >> group and chair interest in this, I'd be happy to help out. >> >> -- Flemming >> >> >> Colin Perkins wrote: >> >>> On 13 Oct 2005, at 19:47, Dan Wing wrote: >>> >>>>>> What do you mean by 'interoperate'? My read of -avt-rtcp- >>>>>> feedback-11 is >>>>>> that both sides of an offer/answer would need to understand >>>>>> the RTP/AVPF profile. >>>>> >>>>> >>>>> >>>>> >>>>> See section 5 of draft-ietf-avt-rtcp-feedback-11.txt >>>> >>>> >>>> >>>> >>>> Yes, I read that before responding. But I'm still failing to >>>> grasp how an >>>> AVPF-unaware endpoint would do anything but reject an m= line >>>> containing >>>> AVPF. Specifically, if my offer says: >>>> >>>> ... >>>> m=audio 49170 RTP/AVPF 0 >>>> ... >>>> >>>> and the answerer only understands RTP/AVP, the answer will contain >>>> only "m=" >>>> for that media line (that is, that media line is rejected). I'll >>>> have to >>>> send another offer with RTP/AVP, under the assumption the reason >>>> it was >>>> rejected was AVPF. This gets really messy >>>> >>>> It's the same problem of sending RTP/SAVP -- the answer won't >>>> understand >>>> "SAVP" and will reject that media line. >>> >>> >>> >>> >>> Sure, but since RTP/AVP and RTP/AVPF are compatible, you can offer >>> both with the same port, and have the receiver choose which to >>> accept (per sdp-new-25 section 5.14). Not ideal, but I think it >>> solves this case. >>> >>> Colin >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Dec 07 05:16:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjwLp-0004vN-Q7; Wed, 07 Dec 2005 05:16:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjwLo-0004u2-1f for mmusic@megatron.ietf.org; Wed, 07 Dec 2005 05:16:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11630 for ; Wed, 7 Dec 2005 05:15:46 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjwhS-0001Dv-ND for mmusic@ietf.org; Wed, 07 Dec 2005 05:39:04 -0500 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:50757) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1EjwLZ-0006nh-2j for mmusic@ietf.org; Wed, 07 Dec 2005 10:16:25 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <71E38194-0CF9-4A26-8068-1B6410B71338@csperkins.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF MMUSIC working group From: Colin Perkins Date: Wed, 7 Dec 2005 10:16:25 +0000 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] IPR disclosure relating to ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org The secretariat has informed us that they have received an IPR disclosure statement entitled "Tandberg Telecom AS's statement about IPR claimed in draft-ietf-mmusic-ice-06.txt". Details can be found on the IETF IPR page: https://datatracker.ietf.org/public/ipr_list.cgi A direct link to the disclosure appears to be: https://datatracker.ietf.org/public/ipr_search.cgi? option=document_search&id_document_tag=11119 Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 08 15:50:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSiV-0007Ux-TM; Thu, 08 Dec 2005 15:50:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSiJ-0007IG-Px; Thu, 08 Dec 2005 15:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09314; Thu, 8 Dec 2005 15:49:10 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkSiL-0000l4-KG; Thu, 08 Dec 2005 15:50:06 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EkSiH-0007wN-DY; Thu, 08 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Dec 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-fec-grouping-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : FEC Grouping Semantics in SDP Author(s) : A. Li Filename : draft-ietf-mmusic-fec-grouping-02.txt Pages : 7 Date : 2005-12-8 This document defines the semantics that allows for grouping of forward error correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document is to be used with Grouping of Media Lines in the Session Description Protocol (RFC 3388) to group together "m" lines in the same session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fec-grouping-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-fec-grouping-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-fec-grouping-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-8115810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-fec-grouping-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-fec-grouping-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-8115810.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Fri Dec 09 22:38:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkvZa-0002IY-4B; Fri, 09 Dec 2005 22:38:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkvZX-0002Eh-LE; Fri, 09 Dec 2005 22:38:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04884; Fri, 9 Dec 2005 22:38:01 -0500 (EST) Message-Id: <200512100338.WAA04884@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkvZq-0006Tj-8j; Fri, 09 Dec 2005 22:39:15 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkvZJ-000Dxi-2e; Sat, 10 Dec 2005 03:38:41 +0000 To: hartmans-ietf@mit.edu, housley@vigilsec.com, hardie@qualcomm.com Date: Fri, 09 Dec 2005 19:38:41 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 Cc: mmusic@ietf.org, xcon@ietf.org, gonzalo.camarillo@ericsson.com, jon.peterson@neustar.biz, mankin@psg.com Subject: [MMUSIC] Progressing/Resolving the IESG Review of the BFCP specs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Russ, Sam, Ted - Gonzalo has worked with you all, and spoke to the respective working groups. He has published revisions of the two specs which we believe should resolve your Discusses. Below are his comments on how. I've added a bit of commentary inline at a few places [AJM: ] Please let us know if you are able to clear now. Allison ------ Gonzalo writes --- I have put together new revisions of the BFCP drafts. They should address all the discusses in the ID tracker. http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-06.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bfcp-03.txt Below I provide detailed answers to all the discusses: MMUSIC document: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1786&filename=draft-ietf-mmusic-sdp-bfcp > Bill Fenner: > > Discuss [2005-09-01]: Port 20000 belongs to a protocol named 'DNP'; > should this example be from the dynamic port range (49152-65535) or > should bfcp have an IANA-assigned port number? The draft now uses ports in the dynamic port range. [AJM: Bill has cleared his Discuss] > Sam Hartman: > > Discuss [2005-08-31]: 1) Please replace the RFc 1750 reference with > RFC 4086. I have removed this reference as a result of removing the digest mechanism. > > 2) RFC 3548 is an informational RFC but is referenced as a normative > reference; RFC 3967 requires that this fact be mentioned in the last > call. It was not. This document needs to be last called again or > that reference changed. [Yes, I think this requirement is wrong; I > also understand the argument that we should follow our rules > consistently] I have removed this reference as a result of removing the digest mechanism. 3) I'm uncomfortable with this document being approved > before draft-ietf-mmusic-media-tls. Based on how this protocol > works, I suspect I have comments on that draft and depending on how > those comments are resolved, I think this draft may change. In > particular, I'm concerned about cases where the active open side of > the connection is the TLS server, the handling of the fingerprint > attribute and some concerns about asymmetry in this protocol. [AJM: Sam, draft-ietf-mmusic-media-tls is in IETF Last Call now - I am shepherding it. There will be no change initiated by the working group. We really need your comments on the draft - I solicited this from you again in a pre-IETF Last Call heads up. There's some time pressure because of outside bodies calling these protocols critical dependencies...] This draft normatively depends on the SDP TLS draft. So, in any case, it will need to wait for it before it can be published as an RFC. > > 4) This document is not aligned with the main BFCP document. First, > if the server can do active opens then section 6 and 14 of the BFCP > document need to discuss that. If the authors of this document > confirm that this document's behavior is correct, then I can amend my > BFCP discuss. I have clarified in the main BFCP spec that the floor control server can do active opens. > 5) The authentication handling in this document is not aligned with > BFCP. Section 8.1 of this document implies that digest is not used > if TLS is used; as discussed by section 9.2 of the BFCP document, > BFCP seems to support modes where both TLS and digest are used. > Similarly, section 8.2.1 only allows the digest shared secret to be > negotiated for tcp/bfcp not tcp/tls/bfcp. Again, I'm happy if these > document are aligned in either direction. I have removed the digest mechanism from the drafts. Now TLS is mandated. > 6) IT seems like the attributes discussed in section 8.1 need to be > integrity protected. However the security considerations does not > discuss this issue. I have removed the digest mechanism from the drafts. Now TLS is mandated. > Comment [2005-08-31]: I'm not sure I see a way that a server can > offer both a TLS and non-TLS stream using this media type. If > clients end up being required to support TLS tihs probably doesn't > matter. However it may be an issue if clients are not required to > support TLS. Perhaps I'm missing some information about how > offer/answer works. It definitely seems that two m lines would be > wrong because then a client could accept both of them. Now TLS is mandated. > > Russ Housley: > > Discuss [2005-09-01]: > > The value "c2hhcmVkLXNlY3JldA==" is used throughout the document as > the shared secret example value. While the ASCII string that was > encoded to make this value is cute, the string is not long enough. > RFC 2104 recommends that the key for HMAC-SHA-1 be 20 octets. I have removed the digest mechanism from the drafts. Now TLS is mandated. > I find the structure of section 8 very confusing. The authentication > of the SIP session that is used to perform an offer/answer exchange > is not clearly separated from the authentication of the BFCP protocol > entities. Further, if the 'fingerprint' attribute is not present, > what checks must be performed to ensure that the non-self-signed > certificate used for offer/answer exchange authentication belongs to > to the same party as the non-self-signed certificate used with > BFCP/TLS/TCP. This (and perhaps other related topics) belong in a > subsection that does not currently exist. With the removal of the digest mechanism everything should be clearer. > Section 8 says: >> >> Note that when mutual authentication is performed using TLS, it is >> not necessary to use this digest mechanism. >> > This does not agree with draft-ietf-xcon-bfcp-05, which says that the > digest mechanism must be used for the first message, even when TLS > is employed. > > Section 8.1 says: >> >> ... the certificate provided at the TLS-level must be signed by a >> certificate authority known to other party. >> > This is not quite correct, and the terminology does not align with > RFC 3280. I suggest: >> >> ... the certificate provided at the TLS-level MUST either be >> directly signed by one of the other party's trust anchors or be >> validated using a certification path that terminates at one of the >> other party's trust anchors. >> I have modifies the text according to your suggestion. > Also, a normative reference to RFC 3280 in this section is desirable. > Added. > > Section 8.2.1 says: >> >> The key-params field SHOULD use the 'inline' key method followed by >> a base64-encoded [6] unguessable secret [1]. >> > Please state the size of the shared secret value. I suspect that the > size depends on the selected integrity check function. The digest mechanism has been removed from the draft. > > Bert Wijnen: > > Comment [2005-09-01]: > > This document has a normative reference: [9] Levin, O. and G. > Camarillo, "The SDP (Session Description Protocol) Label Attribute", > draft-levin-mmmusic-sdp-media-label-00 (work in progress), July 2004. > > > and that document is an individual Internet-Draft, that also has > expired. So what impact does this have? I have updated the reference to draft-ietf-mmusic-sdp-media-label, which is a WG item. [AJM: and it is in the RFC Editor Queue] XCON document: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1785&filename=draft-ietf-xcon-bfcp > Brian Carpenter: > > Comment [2005-09-01]: > Comment from John Loughney > > Intro says: > > The Requirements for Floor Control Protocol [10] list a set of > requirements that need to be met by floor control protocols. The > Binary Floor Control Protocol (BFCP), which is specified in this > document, meets these requirements. > > -> "Requirements for Floor Control Protocol" seems to have expired. > Awfully hard to know if the requirements have been met by this > protocol, if they've expired ... The requirements document has already been approved and is in the RFC Editor's queue at this point. > > Ted Hardie: > > Discuss [2005-08-31]: > The document says that it fulfills the requirements of > draft-ietf-xcon-floor-control-req, but the draft > has apparently expired. The requirements document has already been approved and is in the RFC Editor's queue at this point. > > The document describes the USER-URI field by saying: > > Text: this field contains the UTF-8 encoded URI of the user. > > Further details on what is meant by this seem required to get interoperable > use. The document > does note that it is returned in responses to User Query messages, but it is not > clear if it is > limited to a contact uri or has a broader applicability. I have clarified the scope of this attribute. > > Sam Hartman: > > Discuss [2005-08-31]: > Section 5.2 says: > > Length: this 8-bit field contains the length of the attribute in > > bytes, excluding any padding defined for specific attributes. > If I understand this text correctly, it means that a new attribute > can be defined with padding requirements such that the length byte > is not enough to find the end of this attribute and the beginning > of the next attribute because the padding is not included in the > length. This seems against the goal of having extensible attributes. All the attributes are32-bit aligned. Therefore, it is always possible to find the next attribute. > Section 5.2.7 indicates that the length of the DIGEST attribute > payload is always 24 bytes. This seems to be composed of: > header = 2 bytes > algorithm = 1 byte > digest = 20 bytes (for HMAC-SHA-1) > padding = 2 bytes > This adds up to 25 bytes. Please correct. Also, the size of > this attribute should not be constant. How would HMAC-SHA-256 > be supported? The digest mechanism has been removed. > Section 5.2.7 says: > > When HMAC-SHA1 is used, the input text needs to be padded so as > > to be a multiple of 64 bytes. > Why? HMAC-SHA-1 can be used to authenticate messages of arbitrary > size. The digest mechanism has been removed. > > Section 7 makes TLS mandatory for servers but not for clients. > The authors need to consider the requirements of RFC 4107. I believe > this specification requires automated key management; if there is a > convincing argument why manual key management is appropriate, it needs > to be stated clearly, probably deserving a subsection in the security > considerations. I think the easiest fix is to require clients to > implement TLS so that there is mandatory automated key management. Now TLS is mandatory for all BFCP nodes (both servers and clients). > > In sections 6 and 7, how does a client know whether a particular > connection is using TLS? How about a server? Are separate ports > required? TLS now is mandatory. I have also added text saying that nodes should check that messages coming over a given TLS connection use a valid User ID to avoid attacks. > There is a conflict between section 9.1 and 9.2. Section 9.1 assumes > that both parties in the TLS exchange have certificates. However > section 9.2 assumes that the client is not authenticated and is using > the digest attribute for authentication. Please resolve this > conflict. I think the conflict also spills over into the text in > section 14. Presumably the desire is to support clients without > certificates; make it clear in section 9.1 that this is permitted and > make it clear in sections 9.2 and 14 that there are three modes to > consider: TLS with all parties having certificates, TLS with the > server having a certificate but the client not having a certificate, > and no TLS protection at all. Also, what happens if a client has a > certificate that the server is unwilling accept? Does it use the > digest attribute? If so, how does it know it should use the digest > attribute instead of depending on TLS level authentication? Now digest has been removed and TLS with self-signed certificates is the mechanism to use. > The assumption in section 9.2 seems to be that servers are > authenticated to clients via TLS, but this is only true if the client > can validate the certificate. In the absence of TLS protection, the > client's DIGEST-protected message can be replayed by a man-in-the- > middle to a real server. If the DIGEST attribute is only required > for the first message, then the man-in-the-middle can inject future > messages. The document needs to specify under what circumstances > clients verify certificates, and several details on certificate > verification need to be described. What subject names are expected > in the server's certificate? Must the client always have fingerprints > of certificates through mechanisms similar to [13]? If certificates > are ever accepted without verification, then the vulnerability to > man-in-the-middle with only the first message containing DIGEST > attributes needs to be discussed in the security considerations > section. Now TLS is mandatory and digest has been removed. > Section 9.2 needs to be strengthened. It needs to require that the > DIGEST attribute be the last attribute in the message. I want to > confirm that clients only use the NONCE once and that they must wait > for a server response to see if the NONCE attribute is included in > order to know whether to include a NONCE attribute in the next > message. Is 16-bits really larger enough for a nonce? Given the > requirement that "and a NONCE attribute with a nonce value that is > unguessable by attackers," 2**16 possible values seems too few. > Further, please reference RFC 4086 regarding nonce value generation. > Why does the nonce need to be unguessable anyway? It seems like > requiring nonces never be reused with a given shared secret is > sufficient. Digest has been removed. > > Section 9.2, I believe there are problems if an unauthenticated > server can tell a client what nonce value to use. The most serious > problem involves a server that supports TLS and a client that does > not require TLS. An attacker can trick the client into not using > TLS. The attacker sends a message to the server without a NONCE > attribute or DIGEST attribute, sees what nonce value the server > wants, and then generates an error reply to the real client > requesting this nonce value. The client responds with some message > including the NONCE and DIGEST attributes. The attacker then > sends this message to the server. Since the attacker is using TLS > to communicate to the server and since the server only requires > the first message to be authenticated, the attacker may now send any > message authenticated as the client. This attack must be thwarted, > possibly by defining an attribute indicating that a particular > message (is|is not) being sent over a TLS channel. Any remaining > attacks based on the fact that the error containing the nonce > value is not authenticated must be documented. Digest has been removed. > > Section 9.2 chooses not to authenticate messages from the server to > the client. I don't like this design decision and would recommend > that the working group change its mind. However I cannot require this > change. I do require that this decision be clearly documented. This > is especially problematic when the nonce value is sent to the client. > Without the DIGEST attribute on this message, the client has no way > to determine that the nonce value is actually coming from the server. Now TLS is mandatory and digest has been removed. > Section 9.2 assumes that the shared secret can be used with any digest > algorithm. I don't think it is guaranteed that all keys are valid > with all algorithms. For example, HMAC-SHA-1 has a minimum requirement > on the key size. Digest has been removed. > > The security considerations section seems to gloss over many attacks > and simply recommend using TLS. Please do separate security analysis > for the protocol when TLS is used and the protocol when just the > digest attribute is used. Once that is done, I'd like to re-review. Now TLS is mandatory. > > Scott Hollenbeck: > > Comment [2005-08-29]: > The document uses the word "byte" in many places to describe things like pad > values. While I'll agree that a byte contains 8 bits on most modern computers, > it's generally better to use "octet" if 8-bit values are being described. Done. > Russ Housley: > > Comment [2005-08-31]: > > Sam Hartman and I had a long discussion about this document, and > we decided that it would be best if only one DISCUSS ballot position > is posted by a Security Area Director. As a result, Sam is posting > a DISCUSS position, and I am posting a NO-OBJECTION position. The > position posted by Sam is a union of our concerns, and the authors > only need to work with one Security Area Director to resolve the > concerns that are being raised. As a result of my discussions with Sam, I have removed the digest mechanism from the document. > > Bert Wijnen: > > Comment [2005-09-01]: > > I think that this informative reference: > [13] Camarillo, G., "Session Description Protocol (SDP) Format for > Binary Floor Control Protocol (BFCP) Streams", > draft-ietf-mmusic-sdp-bfcp-01 (work in progress), May 2005. > > Should really be a normative reference. As far as I can tell, you better > understand the content of that mmusic-sdb-bfcp if you want to implement > this xcon-bfcp specification. > Changed to normative. Thanks, Gonzalo ------- End of Forwarded Message _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 12 15:49:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElucG-00021s-Am; Mon, 12 Dec 2005 15:49:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElucB-00021R-W8; Mon, 12 Dec 2005 15:49:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24927; Mon, 12 Dec 2005 15:48:47 -0500 (EST) Message-Id: <200512122048.PAA24927@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elud2-000626-SD; Mon, 12 Dec 2005 15:50:38 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eluc9-000Dc5-A1; Mon, 12 Dec 2005 20:49:41 +0000 To: mmusic@ietf.org Date: Mon, 12 Dec 2005 12:49:41 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: hardie@qualcomm.com, jon.peterson@neustar.biz, hartmans-ietf@mit.edu, housley@vigilsec.com, gonzalo.camarillo@ericsson.com, xcon@ietf.org Subject: [MMUSIC] Re: Progressing/Resolving the IESG Review of the BFCP specs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Thanks to Russ and Ted for the prompt re-review of the BFCP documents. Russ wrote: > This document depends on the fingerprint Attribute definition in > [10], which is draft-ietf-mmusic-comedia-tls-05. The definition of > the fingerprint attribute includes: hash-func = "sha-1" / "sha-224" / "sha-256" / "sha-384" / "sha-512" / "md5" / "md2" / token ; Additional hash functions can only come ; from updates to RFC 3279 > RFC 3279 does not define the short strings used here. RFC 3279 > provides ASN.1 object identifiers, which are not suitable > here. draft-ietf-mmusic-comedia-tls needs to say how these > identifiers will be assigned. Will IANA maintain a registry? Good point. I'll note to the WG that Russ also sent this to the IESG as a Last Call comment on the document. There are some instances when attribute values are registered in IANA, not just the att-field. One that is comparable is the key management protocol identifier from draft-ietf-mmusic-kmgmt-ext. So a suggestion is to add to the IANA Considerations a crisp new sub-registry for the hash-func values in the fingerprint attribute. Its rules for registration can be that new identifiers are permitted only for hash functions found in RFC 3279 or updates of RFC 3279. Does the editor want to propose some IANA Considerations text? Allison (wearing the hat of an AD shepherd for comedia-tls) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 13 04:16:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6H9-0008TU-8B; Tue, 13 Dec 2005 04:16:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElsqA-00064p-6u; Mon, 12 Dec 2005 13:56:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01639; Mon, 12 Dec 2005 13:54:56 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elsqo-0007Tz-VJ; Mon, 12 Dec 2005 13:56:45 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBCItSul031200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Dec 2005 10:55:29 -0800 Received: from [67.188.157.106] (carbuncle.qualcomm.com [129.46.225.16]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBCItPFA013072; Mon, 12 Dec 2005 10:55:26 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200512100338.jBA3ckj3018566@moria.qualcomm.com> References: <200512100338.jBA3ckj3018566@moria.qualcomm.com> Date: Mon, 12 Dec 2005 10:55:19 -0800 To: mankin@psg.com, hartmans-ietf@mit.edu, housley@vigilsec.com From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 X-Mailman-Approved-At: Tue, 13 Dec 2005 04:16:44 -0500 Cc: mmusic@ietf.org, xcon@ietf.org, gonzalo.camarillo@ericsson.com, jon.peterson@neustar.biz, mankin@psg.com Subject: [MMUSIC] Re: Progressing/Resolving the IESG Review of the BFCP specs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org I've cleared my DISCUSS. Thanks for the updates on USER-URI; the new text is much clearer, and I think it will help implementors get the right thing done here. regards, Ted At 7:38 PM -0800 12/9/05, Allison Mankin wrote: >Russ, Sam, Ted - > >Gonzalo has worked with you all, and spoke to the respective >working groups. He has published revisions of the two specs >which we believe should resolve your Discusses. Below are his >comments on how. I've added a bit of commentary inline at a few >places [AJM: ] > >Please let us know if you are able to clear now. > >Allison > >------ Gonzalo writes --- > > >I have put together new revisions of the BFCP drafts. They should >address all the discusses in the ID tracker. > >http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-06.txt >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bfcp-03.txt > >Below I provide detailed answers to all the discusses: > >MMUSIC document: >https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1786&filename=draft-ietf-mmusic-sdp-bfcp > >> Bill Fenner: >> >> Discuss [2005-09-01]: Port 20000 belongs to a protocol named 'DNP'; >> should this example be from the dynamic port range (49152-65535) or >> should bfcp have an IANA-assigned port number? > >The draft now uses ports in the dynamic port range. > >[AJM: Bill has cleared his Discuss] > >> Sam Hartman: >> >> Discuss [2005-08-31]: 1) Please replace the RFc 1750 reference with >> RFC 4086. > >I have removed this reference as a result of removing the digest mechanism. > >> >> 2) RFC 3548 is an informational RFC but is referenced as a normative >> reference; RFC 3967 requires that this fact be mentioned in the last >> call. It was not. This document needs to be last called again or >> that reference changed. [Yes, I think this requirement is wrong; I >> also understand the argument that we should follow our rules >> consistently] > >I have removed this reference as a result of removing the digest mechanism. > > 3) I'm uncomfortable with this document being approved >> before draft-ietf-mmusic-media-tls. Based on how this protocol >> works, I suspect I have comments on that draft and depending on how >> those comments are resolved, I think this draft may change. In >> particular, I'm concerned about cases where the active open side of >> the connection is the TLS server, the handling of the fingerprint >> attribute and some concerns about asymmetry in this protocol. > >[AJM: Sam, draft-ietf-mmusic-media-tls is in IETF Last Call now - > I am shepherding it. There will be no change initiated by the > working group. We really need your comments on the draft - > I solicited this from you again in a pre-IETF Last Call heads > up. There's some time pressure because of outside bodies > calling these protocols critical dependencies...] > >This draft normatively depends on the SDP TLS draft. So, in any case, it >will need to wait for it before it can be published as an RFC. > >> >> 4) This document is not aligned with the main BFCP document. First, >> if the server can do active opens then section 6 and 14 of the BFCP >> document need to discuss that. If the authors of this document >> confirm that this document's behavior is correct, then I can amend my >> BFCP discuss. > >I have clarified in the main BFCP spec that the floor control server can >do active opens. > >> 5) The authentication handling in this document is not aligned with >> BFCP. Section 8.1 of this document implies that digest is not used >> if TLS is used; as discussed by section 9.2 of the BFCP document, >> BFCP seems to support modes where both TLS and digest are used. >> Similarly, section 8.2.1 only allows the digest shared secret to be >> negotiated for tcp/bfcp not tcp/tls/bfcp. Again, I'm happy if these >> document are aligned in either direction. > >I have removed the digest mechanism from the drafts. Now TLS is mandated. > >> 6) IT seems like the attributes discussed in section 8.1 need to be >> integrity protected. However the security considerations does not > > discuss this issue. > >I have removed the digest mechanism from the drafts. Now TLS is mandated. > >> Comment [2005-08-31]: I'm not sure I see a way that a server can >> offer both a TLS and non-TLS stream using this media type. If >> clients end up being required to support TLS tihs probably doesn't >> matter. However it may be an issue if clients are not required to >> support TLS. Perhaps I'm missing some information about how >> offer/answer works. It definitely seems that two m lines would be >> wrong because then a client could accept both of them. > >Now TLS is mandated. > >> >> Russ Housley: >> >> Discuss [2005-09-01]: >> >> The value "c2hhcmVkLXNlY3JldA==" is used throughout the document as >> the shared secret example value. While the ASCII string that was >> encoded to make this value is cute, the string is not long enough. >> RFC 2104 recommends that the key for HMAC-SHA-1 be 20 octets. > >I have removed the digest mechanism from the drafts. Now TLS is mandated. > >> I find the structure of section 8 very confusing. The authentication >> of the SIP session that is used to perform an offer/answer exchange >> is not clearly separated from the authentication of the BFCP protocol >> entities. Further, if the 'fingerprint' attribute is not present, >> what checks must be performed to ensure that the non-self-signed >> certificate used for offer/answer exchange authentication belongs to >> to the same party as the non-self-signed certificate used with >> BFCP/TLS/TCP. This (and perhaps other related topics) belong in a >> subsection that does not currently exist. > >With the removal of the digest mechanism everything should be clearer. > >> Section 8 says: >>> >>> Note that when mutual authentication is performed using TLS, it is >>> not necessary to use this digest mechanism. >>> >> This does not agree with draft-ietf-xcon-bfcp-05, which says that the >> digest mechanism must be used for the first message, even when TLS >> is employed. >> >> Section 8.1 says: >>> >>> ... the certificate provided at the TLS-level must be signed by a >>> certificate authority known to other party. >>> >> This is not quite correct, and the terminology does not align with >> RFC 3280. I suggest: >>> >>> ... the certificate provided at the TLS-level MUST either be >>> directly signed by one of the other party's trust anchors or be >>> validated using a certification path that terminates at one of the >>> other party's trust anchors. >>> > >I have modifies the text according to your suggestion. > >> Also, a normative reference to RFC 3280 in this section is desirable. >> > >Added. > >> >> Section 8.2.1 says: >>> >>> The key-params field SHOULD use the 'inline' key method followed by >>> a base64-encoded [6] unguessable secret [1]. >>> >> Please state the size of the shared secret value. I suspect that the >> size depends on the selected integrity check function. > >The digest mechanism has been removed from the draft. > >> >> Bert Wijnen: >> >> Comment [2005-09-01]: >> >> This document has a normative reference: [9] Levin, O. and G. >> Camarillo, "The SDP (Session Description Protocol) Label Attribute", >> draft-levin-mmmusic-sdp-media-label-00 (work in progress), July 2004. >> >> >> and that document is an individual Internet-Draft, that also has >> expired. So what impact does this have? > >I have updated the reference to draft-ietf-mmusic-sdp-media-label, which >is a WG item. > >[AJM: and it is in the RFC Editor Queue] > > >XCON document: >https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1785&filename=draft-ietf-xcon-bfcp > >> Brian Carpenter: >> >> Comment [2005-09-01]: >> Comment from John Loughney >> >> Intro says: >> >> The Requirements for Floor Control Protocol [10] list a set of >> requirements that need to be met by floor control protocols. The >> Binary Floor Control Protocol (BFCP), which is specified in this >> document, meets these requirements. >> >> -> "Requirements for Floor Control Protocol" seems to have expired. > > Awfully hard to know if the requirements have been met by this >> protocol, if they've expired ... > >The requirements document has already been approved and is in the RFC >Editor's queue at this point. > >> >> Ted Hardie: >> >> Discuss [2005-08-31]: >> The document says that it fulfills the requirements of >> draft-ietf-xcon-floor-control-req, but the draft >> has apparently expired. > >The requirements document has already been approved and is in the RFC >Editor's queue at this point. > >> >> The document describes the USER-URI field by saying: >> >> Text: this field contains the UTF-8 encoded URI of the user. >> >> Further details on what is meant by this seem required to get interoperable >> use. The document >> does note that it is returned in responses to User Query messages, but it is not >> clear if it is >> limited to a contact uri or has a broader applicability. > >I have clarified the scope of this attribute. > >> >> Sam Hartman: >> >> Discuss [2005-08-31]: >> Section 5.2 says: >> > Length: this 8-bit field contains the length of the attribute in >> > bytes, excluding any padding defined for specific attributes. >> If I understand this text correctly, it means that a new attribute >> can be defined with padding requirements such that the length byte >> is not enough to find the end of this attribute and the beginning >> of the next attribute because the padding is not included in the >> length. This seems against the goal of having extensible attributes. > >All the attributes are32-bit aligned. Therefore, it is always possible >to find the next attribute. > >> Section 5.2.7 indicates that the length of the DIGEST attribute >> payload is always 24 bytes. This seems to be composed of: >> header = 2 bytes >> algorithm = 1 byte >> digest = 20 bytes (for HMAC-SHA-1) >> padding = 2 bytes >> This adds up to 25 bytes. Please correct. Also, the size of >> this attribute should not be constant. How would HMAC-SHA-256 >> be supported? > >The digest mechanism has been removed. > >> Section 5.2.7 says: >> > When HMAC-SHA1 is used, the input text needs to be padded so as >> > to be a multiple of 64 bytes. >> Why? HMAC-SHA-1 can be used to authenticate messages of arbitrary >> size. > >The digest mechanism has been removed. > >> >> Section 7 makes TLS mandatory for servers but not for clients. >> The authors need to consider the requirements of RFC 4107. I believe >> this specification requires automated key management; if there is a >> convincing argument why manual key management is appropriate, it needs >> to be stated clearly, probably deserving a subsection in the security >> considerations. I think the easiest fix is to require clients to >> implement TLS so that there is mandatory automated key management. > >Now TLS is mandatory for all BFCP nodes (both servers and clients). > >> >> In sections 6 and 7, how does a client know whether a particular >> connection is using TLS? How about a server? Are separate ports >> required? > >TLS now is mandatory. I have also added text saying that nodes should >check that messages coming over a given TLS connection use a valid User >ID to avoid attacks. > >> There is a conflict between section 9.1 and 9.2. Section 9.1 assumes >> that both parties in the TLS exchange have certificates. However >> section 9.2 assumes that the client is not authenticated and is using >> the digest attribute for authentication. Please resolve this >> conflict. I think the conflict also spills over into the text in >> section 14. Presumably the desire is to support clients without >> certificates; make it clear in section 9.1 that this is permitted and >> make it clear in sections 9.2 and 14 that there are three modes to >> consider: TLS with all parties having certificates, TLS with the >> server having a certificate but the client not having a certificate, >> and no TLS protection at all. Also, what happens if a client has a >> certificate that the server is unwilling accept? Does it use the >> digest attribute? If so, how does it know it should use the digest >> attribute instead of depending on TLS level authentication? > >Now digest has been removed and TLS with self-signed certificates is the > mechanism to use. > >> The assumption in section 9.2 seems to be that servers are >> authenticated to clients via TLS, but this is only true if the client > > can validate the certificate. In the absence of TLS protection, the >> client's DIGEST-protected message can be replayed by a man-in-the- >> middle to a real server. If the DIGEST attribute is only required >> for the first message, then the man-in-the-middle can inject future >> messages. The document needs to specify under what circumstances >> clients verify certificates, and several details on certificate >> verification need to be described. What subject names are expected >> in the server's certificate? Must the client always have fingerprints >> of certificates through mechanisms similar to [13]? If certificates >> are ever accepted without verification, then the vulnerability to >> man-in-the-middle with only the first message containing DIGEST >> attributes needs to be discussed in the security considerations >> section. > >Now TLS is mandatory and digest has been removed. > >> Section 9.2 needs to be strengthened. It needs to require that the >> DIGEST attribute be the last attribute in the message. I want to >> confirm that clients only use the NONCE once and that they must wait >> for a server response to see if the NONCE attribute is included in >> order to know whether to include a NONCE attribute in the next >> message. Is 16-bits really larger enough for a nonce? Given the >> requirement that "and a NONCE attribute with a nonce value that is >> unguessable by attackers," 2**16 possible values seems too few. >> Further, please reference RFC 4086 regarding nonce value generation. >> Why does the nonce need to be unguessable anyway? It seems like >> requiring nonces never be reused with a given shared secret is >> sufficient. > >Digest has been removed. > >> >> Section 9.2, I believe there are problems if an unauthenticated >> server can tell a client what nonce value to use. The most serious >> problem involves a server that supports TLS and a client that does >> not require TLS. An attacker can trick the client into not using >> TLS. The attacker sends a message to the server without a NONCE >> attribute or DIGEST attribute, sees what nonce value the server >> wants, and then generates an error reply to the real client >> requesting this nonce value. The client responds with some message >> including the NONCE and DIGEST attributes. The attacker then >> sends this message to the server. Since the attacker is using TLS >> to communicate to the server and since the server only requires >> the first message to be authenticated, the attacker may now send any >> message authenticated as the client. This attack must be thwarted, >> possibly by defining an attribute indicating that a particular >> message (is|is not) being sent over a TLS channel. Any remaining >> attacks based on the fact that the error containing the nonce >> value is not authenticated must be documented. > >Digest has been removed. > >> >> Section 9.2 chooses not to authenticate messages from the server to >> the client. I don't like this design decision and would recommend >> that the working group change its mind. However I cannot require this >> change. I do require that this decision be clearly documented. This >> is especially problematic when the nonce value is sent to the client. >> Without the DIGEST attribute on this message, the client has no way >> to determine that the nonce value is actually coming from the server. > >Now TLS is mandatory and digest has been removed. > >> Section 9.2 assumes that the shared secret can be used with any digest >> algorithm. I don't think it is guaranteed that all keys are valid >> with all algorithms. For example, HMAC-SHA-1 has a minimum requirement >> on the key size. > >Digest has been removed. > >> >> The security considerations section seems to gloss over many attacks >> and simply recommend using TLS. Please do separate security analysis >> for the protocol when TLS is used and the protocol when just the >> digest attribute is used. Once that is done, I'd like to re-review. > >Now TLS is mandatory. > >> >> Scott Hollenbeck: > > >> Comment [2005-08-29]: >> The document uses the word "byte" in many places to describe things like pad >> values. While I'll agree that a byte contains 8 bits on most modern computers, > > it's generally better to use "octet" if 8-bit values are being described. > >Done. > >> Russ Housley: >> >> Comment [2005-08-31]: >> >> Sam Hartman and I had a long discussion about this document, and >> we decided that it would be best if only one DISCUSS ballot position >> is posted by a Security Area Director. As a result, Sam is posting >> a DISCUSS position, and I am posting a NO-OBJECTION position. The >> position posted by Sam is a union of our concerns, and the authors >> only need to work with one Security Area Director to resolve the >> concerns that are being raised. > >As a result of my discussions with Sam, I have removed the digest >mechanism from the document. > >> >> Bert Wijnen: >> >> Comment [2005-09-01]: >> >> I think that this informative reference: >> [13] Camarillo, G., "Session Description Protocol (SDP) Format for >> Binary Floor Control Protocol (BFCP) Streams", >> draft-ietf-mmusic-sdp-bfcp-01 (work in progress), May 2005. >> >> Should really be a normative reference. As far as I can tell, you better >> understand the content of that mmusic-sdb-bfcp if you want to implement >> this xcon-bfcp specification. >> > >Changed to normative. > > >Thanks, > >Gonzalo > > > >------- End of Forwarded Message _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 13 04:16:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6H9-0008V7-TG; Tue, 13 Dec 2005 04:16:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EltKX-0003n6-Cd for mmusic@megatron.ietf.org; Mon, 12 Dec 2005 14:27:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05573 for ; Mon, 12 Dec 2005 14:26:29 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EltLN-0008WH-Cy for mmusic@ietf.org; Mon, 12 Dec 2005 14:28:18 -0500 Received: (qmail 18273 invoked by uid 0); 12 Dec 2005 19:27:15 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.162.215) by woodstock.binhost.com with SMTP; 12 Dec 2005 19:27:15 -0000 Message-Id: <7.0.0.10.2.20051212142348.0369a800@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Mon, 12 Dec 2005 14:27:17 -0500 To: mankin@psg.com, hartmans-ietf@mit.edu, hardie@qualcomm.com From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 X-Mailman-Approved-At: Tue, 13 Dec 2005 04:16:44 -0500 Cc: mmusic@ietf.org, xcon@ietf.org, gonzalo.camarillo@ericsson.com, jon.peterson@neustar.biz, mankin@psg.com Subject: [MMUSIC] Re: Progressing/Resolving the IESG Review of the BFCP specs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org I cleared my DISCUSS. This document depends on the fingerprint Attribute definition in [10], which is draft-ietf-mmusic-comedia-tls-05. The definition of the fingerprint attribute includes: hash-func = "sha-1" / "sha-224" / "sha-256" / "sha-384" / "sha-512" / "md5" / "md2" / token ; Additional hash functions can only come ; from updates to RFC 3279 RFC 3279 does not define the short strings used here. RFC 3279 provides ASN.1 object identifiers, which are not suitable here. draft-ietf-mmusic-comedia-tls needs to say how these identifiers will be assigned. Will IANA maintain a registry? Russ At 10:38 PM 12/9/2005, Allison Mankin wrote: >Russ, Sam, Ted - > >Gonzalo has worked with you all, and spoke to the respective >working groups. He has published revisions of the two specs >which we believe should resolve your Discusses. Below are his >comments on how. I've added a bit of commentary inline at a few >places [AJM: ] > >Please let us know if you are able to clear now. > >Allison > >------ Gonzalo writes --- > > >I have put together new revisions of the BFCP drafts. They should >address all the discusses in the ID tracker. > >http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-06.txt >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bfcp-03.txt > >Below I provide detailed answers to all the discusses: > >MMUSIC document: >https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1786&filename=draft-ietf-mmusic-sdp-bfcp > > > Bill Fenner: > > > > Discuss [2005-09-01]: Port 20000 belongs to a protocol named 'DNP'; > > should this example be from the dynamic port range (49152-65535) or > > should bfcp have an IANA-assigned port number? > >The draft now uses ports in the dynamic port range. > >[AJM: Bill has cleared his Discuss] > > > Sam Hartman: > > > > Discuss [2005-08-31]: 1) Please replace the RFc 1750 reference with > > RFC 4086. > >I have removed this reference as a result of removing the digest mechanism. > > > > > 2) RFC 3548 is an informational RFC but is referenced as a normative > > reference; RFC 3967 requires that this fact be mentioned in the last > > call. It was not. This document needs to be last called again or > > that reference changed. [Yes, I think this requirement is wrong; I > > also understand the argument that we should follow our rules > > consistently] > >I have removed this reference as a result of removing the digest mechanism. > > 3) I'm uncomfortable with this document being approved > > before draft-ietf-mmusic-media-tls. Based on how this protocol > > works, I suspect I have comments on that draft and depending on how > > those comments are resolved, I think this draft may change. In > > particular, I'm concerned about cases where the active open side of > > the connection is the TLS server, the handling of the fingerprint > > attribute and some concerns about asymmetry in this protocol. > >[AJM: Sam, draft-ietf-mmusic-media-tls is in IETF Last Call now - > I am shepherding it. There will be no change initiated by the > working group. We really need your comments on the draft - > I solicited this from you again in a pre-IETF Last Call heads > up. There's some time pressure because of outside bodies > calling these protocols critical dependencies...] > >This draft normatively depends on the SDP TLS draft. So, in any case, it >will need to wait for it before it can be published as an RFC. > > > > > 4) This document is not aligned with the main BFCP document. First, > > if the server can do active opens then section 6 and 14 of the BFCP > > document need to discuss that. If the authors of this document > > confirm that this document's behavior is correct, then I can amend my > > BFCP discuss. > >I have clarified in the main BFCP spec that the floor control server can >do active opens. > > > 5) The authentication handling in this document is not aligned with > > BFCP. Section 8.1 of this document implies that digest is not used > > if TLS is used; as discussed by section 9.2 of the BFCP document, > > BFCP seems to support modes where both TLS and digest are used. > > Similarly, section 8.2.1 only allows the digest shared secret to be > > negotiated for tcp/bfcp not tcp/tls/bfcp. Again, I'm happy if these > > document are aligned in either direction. > >I have removed the digest mechanism from the drafts. Now TLS is mandated. > > > 6) IT seems like the attributes discussed in section 8.1 need to be > > integrity protected. However the security considerations does not > > discuss this issue. > >I have removed the digest mechanism from the drafts. Now TLS is mandated. > > > Comment [2005-08-31]: I'm not sure I see a way that a server can > > offer both a TLS and non-TLS stream using this media type. If > > clients end up being required to support TLS tihs probably doesn't > > matter. However it may be an issue if clients are not required to > > support TLS. Perhaps I'm missing some information about how > > offer/answer works. It definitely seems that two m lines would be > > wrong because then a client could accept both of them. > >Now TLS is mandated. > > > > > Russ Housley: > > > > Discuss [2005-09-01]: > > > > The value "c2hhcmVkLXNlY3JldA==" is used throughout the document as > > the shared secret example value. While the ASCII string that was > > encoded to make this value is cute, the string is not long enough. > > RFC 2104 recommends that the key for HMAC-SHA-1 be 20 octets. > >I have removed the digest mechanism from the drafts. Now TLS is mandated. > > > I find the structure of section 8 very confusing. The authentication > > of the SIP session that is used to perform an offer/answer exchange > > is not clearly separated from the authentication of the BFCP protocol > > entities. Further, if the 'fingerprint' attribute is not present, > > what checks must be performed to ensure that the non-self-signed > > certificate used for offer/answer exchange authentication belongs to > > to the same party as the non-self-signed certificate used with > > BFCP/TLS/TCP. This (and perhaps other related topics) belong in a > > subsection that does not currently exist. > >With the removal of the digest mechanism everything should be clearer. > > > Section 8 says: > >> > >> Note that when mutual authentication is performed using TLS, it is > >> not necessary to use this digest mechanism. > >> > > This does not agree with draft-ietf-xcon-bfcp-05, which says that the > > digest mechanism must be used for the first message, even when TLS > > is employed. > > > > Section 8.1 says: > >> > >> ... the certificate provided at the TLS-level must be signed by a > >> certificate authority known to other party. > >> > > This is not quite correct, and the terminology does not align with > > RFC 3280. I suggest: > >> > >> ... the certificate provided at the TLS-level MUST either be > >> directly signed by one of the other party's trust anchors or be > >> validated using a certification path that terminates at one of the > >> other party's trust anchors. > >> > >I have modifies the text according to your suggestion. > > > Also, a normative reference to RFC 3280 in this section is desirable. > > > >Added. > > > > > Section 8.2.1 says: > >> > >> The key-params field SHOULD use the 'inline' key method followed by > >> a base64-encoded [6] unguessable secret [1]. > >> > > Please state the size of the shared secret value. I suspect that the > > size depends on the selected integrity check function. > >The digest mechanism has been removed from the draft. > > > > > Bert Wijnen: > > > > Comment [2005-09-01]: > > > > This document has a normative reference: [9] Levin, O. and G. > > Camarillo, "The SDP (Session Description Protocol) Label Attribute", > > draft-levin-mmmusic-sdp-media-label-00 (work in progress), July 2004. > > > > > > and that document is an individual Internet-Draft, that also has > > expired. So what impact does this have? > >I have updated the reference to draft-ietf-mmusic-sdp-media-label, which >is a WG item. > >[AJM: and it is in the RFC Editor Queue] > > >XCON document: >https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1785&filename=draft-ietf-xcon-bfcp > > > Brian Carpenter: > > > > Comment [2005-09-01]: > > Comment from John Loughney > > > > Intro says: > > > > The Requirements for Floor Control Protocol [10] list a set of > > requirements that need to be met by floor control protocols. The > > Binary Floor Control Protocol (BFCP), which is specified in this > > document, meets these requirements. > > > > -> "Requirements for Floor Control Protocol" seems to have expired. > > Awfully hard to know if the requirements have been met by this > > protocol, if they've expired ... > >The requirements document has already been approved and is in the RFC >Editor's queue at this point. > > > > > Ted Hardie: > > > > Discuss [2005-08-31]: > > The document says that it fulfills the requirements of > > draft-ietf-xcon-floor-control-req, but the draft > > has apparently expired. > >The requirements document has already been approved and is in the RFC >Editor's queue at this point. > > > > > The document describes the USER-URI field by saying: > > > > Text: this field contains the UTF-8 encoded URI of the user. > > > > Further details on what is meant by this seem required to get interoperable > > use. The document > > does note that it is returned in responses to User Query > messages, but it is not > > clear if it is > > limited to a contact uri or has a broader applicability. > >I have clarified the scope of this attribute. > > > > > Sam Hartman: > > > > Discuss [2005-08-31]: > > Section 5.2 says: > > > Length: this 8-bit field contains the length of the attribute in > > > bytes, excluding any padding defined for specific attributes. > > If I understand this text correctly, it means that a new attribute > > can be defined with padding requirements such that the length byte > > is not enough to find the end of this attribute and the beginning > > of the next attribute because the padding is not included in the > > length. This seems against the goal of having extensible attributes. > >All the attributes are32-bit aligned. Therefore, it is always possible >to find the next attribute. > > > Section 5.2.7 indicates that the length of the DIGEST attribute > > payload is always 24 bytes. This seems to be composed of: > > header = 2 bytes > > algorithm = 1 byte > > digest = 20 bytes (for HMAC-SHA-1) > > padding = 2 bytes > > This adds up to 25 bytes. Please correct. Also, the size of > > this attribute should not be constant. How would HMAC-SHA-256 > > be supported? > >The digest mechanism has been removed. > > > Section 5.2.7 says: > > > When HMAC-SHA1 is used, the input text needs to be padded so as > > > to be a multiple of 64 bytes. > > Why? HMAC-SHA-1 can be used to authenticate messages of arbitrary > > size. > >The digest mechanism has been removed. > > > > > Section 7 makes TLS mandatory for servers but not for clients. > > The authors need to consider the requirements of RFC 4107. I believe > > this specification requires automated key management; if there is a > > convincing argument why manual key management is appropriate, it needs > > to be stated clearly, probably deserving a subsection in the security > > considerations. I think the easiest fix is to require clients to > > implement TLS so that there is mandatory automated key management. > >Now TLS is mandatory for all BFCP nodes (both servers and clients). > > > > > In sections 6 and 7, how does a client know whether a particular > > connection is using TLS? How about a server? Are separate ports > > required? > >TLS now is mandatory. I have also added text saying that nodes should >check that messages coming over a given TLS connection use a valid User >ID to avoid attacks. > > > There is a conflict between section 9.1 and 9.2. Section 9.1 assumes > > that both parties in the TLS exchange have certificates. However > > section 9.2 assumes that the client is not authenticated and is using > > the digest attribute for authentication. Please resolve this > > conflict. I think the conflict also spills over into the text in > > section 14. Presumably the desire is to support clients without > > certificates; make it clear in section 9.1 that this is permitted and > > make it clear in sections 9.2 and 14 that there are three modes to > > consider: TLS with all parties having certificates, TLS with the > > server having a certificate but the client not having a certificate, > > and no TLS protection at all. Also, what happens if a client has a > > certificate that the server is unwilling accept? Does it use the > > digest attribute? If so, how does it know it should use the digest > > attribute instead of depending on TLS level authentication? > >Now digest has been removed and TLS with self-signed certificates is the > mechanism to use. > > > The assumption in section 9.2 seems to be that servers are > > authenticated to clients via TLS, but this is only true if the client > > can validate the certificate. In the absence of TLS protection, the > > client's DIGEST-protected message can be replayed by a man-in-the- > > middle to a real server. If the DIGEST attribute is only required > > for the first message, then the man-in-the-middle can inject future > > messages. The document needs to specify under what circumstances > > clients verify certificates, and several details on certificate > > verification need to be described. What subject names are expected > > in the server's certificate? Must the client always have fingerprints > > of certificates through mechanisms similar to [13]? If certificates > > are ever accepted without verification, then the vulnerability to > > man-in-the-middle with only the first message containing DIGEST > > attributes needs to be discussed in the security considerations > > section. > >Now TLS is mandatory and digest has been removed. > > > Section 9.2 needs to be strengthened. It needs to require that the > > DIGEST attribute be the last attribute in the message. I want to > > confirm that clients only use the NONCE once and that they must wait > > for a server response to see if the NONCE attribute is included in > > order to know whether to include a NONCE attribute in the next > > message. Is 16-bits really larger enough for a nonce? Given the > > requirement that "and a NONCE attribute with a nonce value that is > > unguessable by attackers," 2**16 possible values seems too few. > > Further, please reference RFC 4086 regarding nonce value generation. > > Why does the nonce need to be unguessable anyway? It seems like > > requiring nonces never be reused with a given shared secret is > > sufficient. > >Digest has been removed. > > > > > Section 9.2, I believe there are problems if an unauthenticated > > server can tell a client what nonce value to use. The most serious > > problem involves a server that supports TLS and a client that does > > not require TLS. An attacker can trick the client into not using > > TLS. The attacker sends a message to the server without a NONCE > > attribute or DIGEST attribute, sees what nonce value the server > > wants, and then generates an error reply to the real client > > requesting this nonce value. The client responds with some message > > including the NONCE and DIGEST attributes. The attacker then > > sends this message to the server. Since the attacker is using TLS > > to communicate to the server and since the server only requires > > the first message to be authenticated, the attacker may now send any > > message authenticated as the client. This attack must be thwarted, > > possibly by defining an attribute indicating that a particular > > message (is|is not) being sent over a TLS channel. Any remaining > > attacks based on the fact that the error containing the nonce > > value is not authenticated must be documented. > >Digest has been removed. > > > > > Section 9.2 chooses not to authenticate messages from the server to > > the client. I don't like this design decision and would recommend > > that the working group change its mind. However I cannot require this > > change. I do require that this decision be clearly documented. This > > is especially problematic when the nonce value is sent to the client. > > Without the DIGEST attribute on this message, the client has no way > > to determine that the nonce value is actually coming from the server. > >Now TLS is mandatory and digest has been removed. > > > Section 9.2 assumes that the shared secret can be used with any digest > > algorithm. I don't think it is guaranteed that all keys are valid > > with all algorithms. For example, HMAC-SHA-1 has a minimum requirement > > on the key size. > >Digest has been removed. > > > > > The security considerations section seems to gloss over many attacks > > and simply recommend using TLS. Please do separate security analysis > > for the protocol when TLS is used and the protocol when just the > > digest attribute is used. Once that is done, I'd like to re-review. > >Now TLS is mandatory. > > > > > Scott Hollenbeck: > > > > Comment [2005-08-29]: > > The document uses the word "byte" in many places to describe > things like pad > > values. While I'll agree that a byte contains 8 bits on most > modern computers, > > it's generally better to use "octet" if 8-bit values are being described. > >Done. > > > Russ Housley: > > > > Comment [2005-08-31]: > > > > Sam Hartman and I had a long discussion about this document, and > > we decided that it would be best if only one DISCUSS ballot position > > is posted by a Security Area Director. As a result, Sam is posting > > a DISCUSS position, and I am posting a NO-OBJECTION position. The > > position posted by Sam is a union of our concerns, and the authors > > only need to work with one Security Area Director to resolve the > > concerns that are being raised. > >As a result of my discussions with Sam, I have removed the digest >mechanism from the document. > > > > > Bert Wijnen: > > > > Comment [2005-09-01]: > > > > I think that this informative reference: > > [13] Camarillo, G., "Session Description Protocol (SDP) Format for > > Binary Floor Control Protocol (BFCP) Streams", > > draft-ietf-mmusic-sdp-bfcp-01 (work in progress), May 2005. > > > > Should really be a normative reference. As far as I can tell, you better > > understand the content of that mmusic-sdb-bfcp if you want to implement > > this xcon-bfcp specification. > > > >Changed to normative. > > >Thanks, > >Gonzalo > > > >------- End of Forwarded Message _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 13 10:06:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmBjU-0006H9-8f; Tue, 13 Dec 2005 10:06:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmBjS-0006GX-4F; Tue, 13 Dec 2005 10:06:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05840; Tue, 13 Dec 2005 10:05:24 -0500 (EST) From: Rod.Walsh@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmBkS-0003Tm-Tc; Tue, 13 Dec 2005 10:07:25 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBDF5crp009778; Tue, 13 Dec 2005 17:05:43 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Dec 2005 17:06:14 +0200 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Dec 2005 17:06:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] FW: New Version Notification - draft-mehta-rmt-flute-sdp-04.txt Date: Tue, 13 Dec 2005 17:06:10 +0200 Message-ID: <7222D14EF47E0840AD88EC7BCBAD8513016C15CB@trebe101.NOE.Nokia.com> In-Reply-To: <4388DB5A.8080803@netlab.hut.fi> Thread-Topic: [MMUSIC] FW: New Version Notification - draft-mehta-rmt-flute-sdp-04.txt Thread-Index: AcXy1SZWmxONkoECTheKGf00/kAPFQNHYqMw To: , , X-OriginalArrivalTime: 13 Dec 2005 15:06:11.0218 (UTC) FILETIME=[C0D57720:01C5FFF6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org, rmt@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Brief status check: Taking into account the thread's earlier comments, questions and answers, the only unresolved issue with draft-mehta-rmt-flute-sdp-04 is the default mode of multiple FLUTE media resolve to a single FLUTE session where CS is not used. Joerg, Colin and Magnus have expressed reservations about this and a (strong) preference that either the default (without CS) is that multiple FLUTE media resolve to different FLUTE sessions and that description of a multi-channel FLUTE session would mandate use of CS in all cases. I have expressed my opinions and technical understanding easily enough so see the thread if you want a technical counter-argument. To make progress (and get my well deserved Christmas vacation), I would be delighted to concede the point and move on. To my knowledge, there is only one obstacle to this. Not 3GPP (who only allow one FLUTE media per SDP and no other media); but DVB. DVB adopted 3GPP's SDP and allowed multi-channel FLUTE sessions by the mechanism described as "the default mode". This is not backwards compatible with the "mandated CS" proposal. To complicate matters only a little, OMA will consider the use of SDP too and since IP over DVB-H is already under commercial trial (i.e. easily the furthest ahead mass role out of FLUTE), not adopting an approach harmonious with DVB would be irrational.=20 So, please help me in constructing an easy to understand explanation of why "the default mode" brakes SDP semantics so we have a tangible hope of presenting this as a change request to DVB (and OMA).=20 So, please, please, please help! Cheers, Rod. PS DVB SDP should be made public at http://www.dvb-h-online.org/technology.htm under CDP spec (A101) anyway now, though it's been frozen a while. PPS Since there seems to be only one issue with the I-D, I'm no longer toying with the idea of splitting into two I-Ds 3GPP-aligned minimal SDP and a full multi-channel multi-session enhanced SDP. (Of course this is an option if it adds yet another month to the process) >-----Original Message----- >From: ext Joerg Ott [mailto:jo@netlab.hut.fi]=20 >Sent: 27 November, 2005 00:02 >To: Colin Perkins >Cc: Magnus Westerlund; Walsh Rod (Nokia-NRC/Tampere);=20 >mmusic@ietf.org; rmt@ietf.org >Subject: Re: [MMUSIC] FW: New Version Notification -=20 >draft-mehta-rmt-flute-sdp-04.txt > >>>> Layering: >>>> The layering with slash notation was our first consideration for=20 >>>> describing multiple channels some time ago (check out the =20 >>>> discussion on differentiating channels in the I-D). Using slash=20 >>>> notation for one but not the other is allowed (again=20 >check the I-D=20 >>>> for reasons). However, limiting all FLUTE sessions to only using=20 >>>> conecutive numbers (addresses for multicast; ports for=20 >unicast) is=20 >>>> unecessary and potentailly harmful as we do not yet a have a=20 >>>> comprehensive set fo RMT CC RFCs for each scheme which has been=20 >>>> dicsussed. i.e. we need a means to group different m-lines=20 >together:=20 >>>> appearing in the same SDP without group:CS for single=20 >FLUTE session=20 >>>> SDPs; have a mid:# belonging to the same group:CS as other=20 >media is=20 >>>> for multiple FLUTE session SDPs. Use of port numbers to=20 >>>> differentiate channels (with the same IP destination/group=20 >address)=20 >>>> is only useful where some other application-based=20 >congestion control=20 >>>> is introduced; indeed it is recommended only for unicast=20 >>>> applications. Differentiation of channels based on IP=20 >>>> destination/group address is appropriate for multicast=20 >sessions with=20 >>>> RMT congestion control. Note, the RMT family uses layers/channels=20 >>>> principally for congestion control. Using them for FEC is allowed=20 >>>> but if it messes with congestion control deployment on the public=20 >>>> Internet can not be assumed feasible. >>> >>> >>> I think that using CS instead of the layering mechanism is=20 >the right=20 >>> choice. However I think one should require the usage of CS for all=20 >>> cases where a FLUTE session contains more than a single channel.=20 >>> That way we are consistent with SDP usage. >>=20 >>=20 >> I agree - my main concern with this draft is the implicit=20 >grouping of=20 >> channels ("m=3D" lines) into a single session, unless otherwise=20 >> signalled. I strongly prefer a solution where separate "m=3D" lines=20 >> denote separate FLUTE sessions, unless the grouping=20 >framework is used. >>=20 > >This was also my main point. The layering suggestion was=20 >meant to encourage thinking about a way that could preserve=20 >the m=3D semantics. > >If we don't do layering, this requires explicit grouping and=20 >it may require a mechanism that ensures that receivers that do=20 >not understand grouping do not get confused (but these may be=20 >more than just the 3GPP clients). > >Quick question: >If FLUTE uses multiple channels (e.g., for congestion control=20 >purposes), can we always identify a "base" channel -- for the=20 >slowest receivers -- (and that would be the single channel if=20 >only one was used)? Could this be the channel, a receiver=20 >listens to if it does not understand the grouping (unless,=20 >maybe, the receiver operates in a specific environment that=20 >implies that all m=3D lines in a SDP session belong together)? > > From a specification mechanics perspective, I would like to=20 >move all the stuff specific to a certain environment (e.g.,=20 >MBMS) into an >(informative) appendix but not use normative language for such=20 >special cases. These considerations are of secondary order=20 >and the spec should express that clearly. > >Joerg > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 13 11:03:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmCcZ-0003Tw-Vq; Tue, 13 Dec 2005 11:03:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmCcO-0003St-IN for mmusic@megatron.ietf.org; Tue, 13 Dec 2005 11:03:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13620 for ; Tue, 13 Dec 2005 11:01:46 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmCcz-0005ke-5d for mmusic@ietf.org; Tue, 13 Dec 2005 11:03:47 -0500 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:64509) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1EmCbf-0002qR-7H; Tue, 13 Dec 2005 16:02:23 +0000 In-Reply-To: <200512122048.PAA24927@ietf.org> References: <200512122048.PAA24927@ietf.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: comedia-tls iana considerations (was Re: [MMUSIC] Re: Progressing/Resolving the IESG Review of the BFCP specs) Date: Tue, 13 Dec 2005 16:02:22 +0000 To: Allison Mankin , Jonathan Lennox X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: "'hardie@qualcomm.com' Hardie" , IETF MMUSIC working group , Jon Peterson , Sam Hartman , Russ Housley , Gonzalo Camarillo X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Allison, [cc'ing Jonathan Lennox, to ensure this doesn't get lost] To confirm: you're proposing an update to comedia-tls IANA considerations, not to sdp-bfcp? Colin On 12 Dec 2005, at 20:49, Allison Mankin wrote: > Thanks to Russ and Ted for the prompt re-review of the BFCP documents. > > Russ wrote: >> This document depends on the fingerprint Attribute definition in >> [10], which is draft-ietf-mmusic-comedia-tls-05. The definition of >> the fingerprint attribute includes: > > hash-func = "sha-1" / "sha-224" / "sha-256" / > "sha-384" / "sha-512" / > "md5" / "md2" / token > ; Additional hash functions can only > come > ; from updates to RFC 3279 > >> RFC 3279 does not define the short strings used here. RFC 3279 >> provides ASN.1 object identifiers, which are not suitable >> here. draft-ietf-mmusic-comedia-tls needs to say how these >> identifiers will be assigned. Will IANA maintain a registry? > > Good point. I'll note to the WG that Russ also sent this to the IESG > as a Last Call comment on the document. > > There are some instances when attribute values are registered in IANA, > not just the att-field. One that is comparable is the key management > protocol identifier from draft-ietf-mmusic-kmgmt-ext. > > So a suggestion is to add to the IANA Considerations a crisp new > sub-registry for the hash-func values in the fingerprint attribute. > Its rules for registration can be that new identifiers are > permitted only for hash functions found in RFC 3279 or updates > of RFC 3279. > > Does the editor want to propose some IANA Considerations text? > > Allison (wearing the hat of an AD shepherd for comedia-tls) > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 13 11:08:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmChG-0004Pz-Eb; Tue, 13 Dec 2005 11:08:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmChE-0004Pl-Iq for mmusic@megatron.ietf.org; Tue, 13 Dec 2005 11:08:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14133 for ; Tue, 13 Dec 2005 11:07:11 -0500 (EST) Message-Id: <200512131607.LAA14133@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmCiF-0005wr-Iq for mmusic@ietf.org; Tue, 13 Dec 2005 11:09:12 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmCh7-000Kkq-PR; Tue, 13 Dec 2005 16:08:01 +0000 To: Colin Perkins Subject: Re: comedia-tls iana considerations (was Re: [MMUSIC] Re: Progressing/Resolving the IESG Review of the BFCP specs) Date: Tue, 13 Dec 2005 08:08:01 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Jonathan Lennox , "'hardie@qualcomm.com' Hardie" , IETF MMUSIC working group , Jon Peterson , mankin@psg.com, Sam Hartman , Russ Housley , Gonzalo Camarillo X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Colin, > To confirm: you're proposing an update to comedia-tls IANA > considerations, not to sdp-bfcp? Yes, I propose an update to the comedia-tls IANA considerations, not to sdp-bfcp. The sub-registry would be requested in comedia-tls, where hash-func is defined. Allison _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 13 11:18:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmCrc-0007C1-KN; Tue, 13 Dec 2005 11:18:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmCrZ-0007Bh-SW for mmusic@megatron.ietf.org; Tue, 13 Dec 2005 11:18:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15842 for ; Tue, 13 Dec 2005 11:17:48 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EmCsX-0006Qc-Ao for mmusic@ietf.org; Tue, 13 Dec 2005 11:19:50 -0500 Received: (qmail 25365 invoked by uid 0); 13 Dec 2005 16:18:40 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (70.21.115.66) by woodstock.binhost.com with SMTP; 13 Dec 2005 16:18:40 -0000 Message-Id: <7.0.0.10.2.20051213111809.063106e0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Tue, 13 Dec 2005 11:18:21 -0500 To: Colin Perkins , Allison Mankin , Jonathan Lennox From: Russ Housley Subject: Re: comedia-tls iana considerations (was Re: [MMUSIC] Re: Progressing/Resolving the IESG Review of the BFCP specs) In-Reply-To: References: <200512122048.PAA24927@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: "'hardie@qualcomm.com' Hardie" , Sam Hartman , IETF MMUSIC working group , Jon Peterson , Gonzalo Camarillo X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Correct. At 11:02 AM 12/13/2005, Colin Perkins wrote: >Allison, > >[cc'ing Jonathan Lennox, to ensure this doesn't get lost] > >To confirm: you're proposing an update to comedia-tls IANA >considerations, not to sdp-bfcp? > >Colin > > > > >On 12 Dec 2005, at 20:49, Allison Mankin wrote: >>Thanks to Russ and Ted for the prompt re-review of the BFCP documents. >> >>Russ wrote: >>>This document depends on the fingerprint Attribute definition in >>>[10], which is draft-ietf-mmusic-comedia-tls-05. The definition of >>>the fingerprint attribute includes: >> >> hash-func = "sha-1" / "sha-224" / "sha-256" / >> "sha-384" / "sha-512" / >> "md5" / "md2" / token >> ; Additional hash functions can only >>come >> ; from updates to RFC 3279 >> >>>RFC 3279 does not define the short strings used here. RFC 3279 >>>provides ASN.1 object identifiers, which are not suitable >>>here. draft-ietf-mmusic-comedia-tls needs to say how these >>>identifiers will be assigned. Will IANA maintain a registry? >> >>Good point. I'll note to the WG that Russ also sent this to the IESG >>as a Last Call comment on the document. >> >>There are some instances when attribute values are registered in IANA, >>not just the att-field. One that is comparable is the key management >>protocol identifier from draft-ietf-mmusic-kmgmt-ext. >> >>So a suggestion is to add to the IANA Considerations a crisp new >>sub-registry for the hash-func values in the fingerprint attribute. >>Its rules for registration can be that new identifiers are >>permitted only for hash functions found in RFC 3279 or updates >>of RFC 3279. >> >>Does the editor want to propose some IANA Considerations text? >> >>Allison (wearing the hat of an AD shepherd for comedia-tls) >> >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 13 13:33:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmExn-0002ck-0Q; Tue, 13 Dec 2005 13:33:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmExd-0002br-H5; Tue, 13 Dec 2005 13:33:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03717; Tue, 13 Dec 2005 13:32:04 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmEyU-0003Ca-Ad; Tue, 13 Dec 2005 13:34:08 -0500 Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jBDIWpQw001230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Dec 2005 13:32:51 -0500 (EST) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.3/8.13.3) with ESMTP id jBDIWoG2089570; Tue, 13 Dec 2005 13:32:50 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.3/8.13.3/Submit) id jBDIWkxr089567; Tue, 13 Dec 2005 13:32:46 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17311.5070.589311.939533@cnr.cs.columbia.edu> Date: Tue, 13 Dec 2005 13:32:46 -0500 To: Russ Housley Subject: Re: [MMUSIC] Re: Progressing/Resolving the IESG Review of the BFCP specs In-Reply-To: <7.0.0.10.2.20051212142348.0369a800@vigilsec.com> References: <7.0.0.10.2.20051212142348.0369a800@vigilsec.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.8 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: hardie@qualcomm.com, mmusic@ietf.org, jon.peterson@neustar.biz, mankin@psg.com, hartmans-ietf@mit.edu, xcon@ietf.org, gonzalo.camarillo@ericsson.com X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org On Monday, December 12 2005, "Russ Housley" wrote to "mankin@psg.com, hartmans-ietf@mit.edu, hardie@qualcomm.com, mmusic@ietf.org, xcon@ietf.org, gonzalo.camarillo@ericsson.com, jon.peterson@neustar.biz, mankin@psg.com" saying: > This document depends on the fingerprint Attribute definition in > [10], which is draft-ietf-mmusic-comedia-tls-05. The definition of > the fingerprint attribute includes: > > hash-func = "sha-1" / "sha-224" / "sha-256" / > "sha-384" / "sha-512" / > "md5" / "md2" / token > ; Additional hash functions can only come > ; from updates to RFC 3279 > > RFC 3279 does not define the short strings used here. RFC 3279 > provides ASN.1 object identifiers, which are not suitable > here. draft-ietf-mmusic-comedia-tls needs to say how these > identifiers will be assigned. Will IANA maintain a registry? It could be an IANA registry; I can write an IANA considerations section. A registry of hash function names seems like something that's useful more broadly than just for the TLS Comedia fingerprint, though. For instance, at some point RFC 2617 is going to need new hash functions. Should this problem be solved in more generality? -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 16 15:45:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMRv-0002S4-7B; Fri, 16 Dec 2005 15:45:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMRs-0002RX-UY; Fri, 16 Dec 2005 15:45:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12191; Fri, 16 Dec 2005 15:44:04 -0500 (EST) Message-Id: <200512162044.PAA12191@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnMTY-0006Lg-20; Fri, 16 Dec 2005 15:46:49 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnMRa-000MNT-Q5; Fri, 16 Dec 2005 20:44:46 +0000 To: Sam Hartman Date: Fri, 16 Dec 2005 12:44:46 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: hardie@qualcomm.com, mmusic@ietf.org, jon.peterson@neustar.biz, mankin@psg.com, housley@vigilsec.com, xcon@ietf.org, gonzalo.camarillo@ericsson.com Subject: [MMUSIC] Re: Progressing/Resolving the IESG Review of the BFCP specs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Thanks to Sam for his responsive re-review. So, XCON and MMUSIC Working Groups: draft-ietf-xcon-bfcp-06.txt is approved now draft-ietf-mmusic-sdp-bfcp-03.txt is approved now Congratulations! The normative dependencies, the TLS comedia and sdp-new, are now well into the pipeline. We are just finishing IANA's questions on sdp-new before approval; TLS comedia is in IETF Last Call and should go before the IESG at the beginning of January. So, news on that next year :) Allison _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Dec 17 06:03:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnZqA-0000rF-Mh; Sat, 17 Dec 2005 06:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnZq8-0000r7-9N for mmusic@megatron.ietf.org; Sat, 17 Dec 2005 06:03:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09750 for ; Sat, 17 Dec 2005 06:01:58 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnZru-0001Lt-SK for mmusic@ietf.org; Sat, 17 Dec 2005 06:04:52 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63030 helo=[192.168.0.2]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1EnZpp-0004g3-7O; Sat, 17 Dec 2005 11:02:41 +0000 In-Reply-To: <200512162044.PAA12191@ietf.org> References: <200512162044.PAA12191@ietf.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <424BE7BD-C751-4C27-98E8-A86F6045124D@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Re: Progressing/Resolving the IESG Review of the BFCP specs Date: Sat, 17 Dec 2005 11:02:40 +0000 To: mankin@psg.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC working group , Jon Peterson X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org On 16 Dec 2005, at 20:44, Allison Mankin wrote: > Thanks to Sam for his responsive re-review. > > So, XCON and MMUSIC Working Groups: > > draft-ietf-xcon-bfcp-06.txt is approved now > draft-ietf-mmusic-sdp-bfcp-03.txt is approved now > > Congratulations! > > The normative dependencies, the TLS comedia and sdp-new, are > now well into the pipeline. We are just finishing IANA's questions > on sdp-new before approval There will be a minor update to sdp-new before approval, to address the General Area review team's comments (see the tracker). There are enough minor editorial details that it's easier to submit an updated draft than to do an RFC editor note. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Dec 17 06:04:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnZrz-00015F-Rn; Sat, 17 Dec 2005 06:04:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMBf-0007Gg-09; Fri, 16 Dec 2005 15:28:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10446; Fri, 16 Dec 2005 15:27:18 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnMDJ-0005pN-Ax; Fri, 16 Dec 2005 15:30:02 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 856A6E0070; Fri, 16 Dec 2005 15:28:09 -0500 (EST) To: mankin@psg.com References: <200512100338.jBA3cht8022206@fort-point-station.mit.edu> From: Sam Hartman Date: Fri, 16 Dec 2005 15:28:09 -0500 In-Reply-To: <200512100338.jBA3cht8022206@fort-point-station.mit.edu> (Allison Mankin's message of "Fri, 09 Dec 2005 19:38:41 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 X-Mailman-Approved-At: Sat, 17 Dec 2005 06:04:54 -0500 Cc: hardie@qualcomm.com, mmusic@ietf.org, jon.peterson@neustar.biz, housley@vigilsec.com, gonzalo.camarillo@ericsson.com, xcon@ietf.org Subject: [MMUSIC] Re: Progressing/Resolving the IESG Review of the BFCP specs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org I'm clearing all my discusses on the BFCP documents. Thanks for the great work. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 20 15:50:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooRd-0007Jl-6x; Tue, 20 Dec 2005 15:50:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooQu-0006r5-U0; Tue, 20 Dec 2005 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04295; Tue, 20 Dec 2005 15:49:00 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EooTM-0005Xo-Ru; Tue, 20 Dec 2005 15:52:37 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EooQr-0008RU-L1; Tue, 20 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Dec 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-img-framework-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Framework for the Usage of Internet Media Guides Author(s) : Y. Nomura, et al. Filename : draft-ietf-mmusic-img-framework-09.txt Pages : 23 Date : 2005-12-20 This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using SDP, SDPng or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols and the need for additional work to create an IMG delivery infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-framework-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-img-framework-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-img-framework-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-20123525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-img-framework-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-img-framework-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-20123525.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Tue Dec 20 15:50:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooRd-0007KF-Vl; Tue, 20 Dec 2005 15:50:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EooQv-0006r8-18; Tue, 20 Dec 2005 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04296; Tue, 20 Dec 2005 15:49:00 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EooTM-0005Xr-SE; Tue, 20 Dec 2005 15:52:37 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EooQr-0008Rd-Mu; Tue, 20 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Dec 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-img-req-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Requirements for Internet Media Guides Author(s) : Y. Nomura, et al. Filename : draft-ietf-mmusic-img-req-08.txt Pages : 23 Date : 2005-12-20 This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-img-req-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-img-req-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-20123816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-img-req-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-img-req-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-20123816.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Tue Dec 20 18:27:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoqtH-0001TC-LB; Tue, 20 Dec 2005 18:27:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoqtC-0001RB-70; Tue, 20 Dec 2005 18:27:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15792; Tue, 20 Dec 2005 18:26:23 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eoqvi-0002tV-3I; Tue, 20 Dec 2005 18:30:02 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EoqtB-0004M5-D0; Tue, 20 Dec 2005 18:27:25 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 20 Dec 2005 18:27:25 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mmusic chair , Internet Architecture Board , mmusic mailing list , mmusic chair , RFC Editor Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams' to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org The IESG has approved the following document: - 'Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams ' as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bfcp-03.txt Technical Summary This document specifies how to describe Basic Floor Control Protocol (BFCP) streams in SDP session descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and their answers. BFCP is defined by an accompanying specification from the XCON working group. This document also describes key management and security principles for BFCP establishment, using existing protocol capabilities available through SDP. Working Group Summary There was strong working group consensus behind this draft. Protocol Quality The protocol has been reviewed by the MMUSIC working group. It defines a number of new SDP parameters within the existing framework. The new parameters are not controversial. Allison Mankin has acted as the Area Director for the document in order to coordinate this document with the XCON BFCP document. Colin Perkins is the WG Chair shepherd for this document. The Editor, Gonzalo Camarillo, took the initiative in shepherding the Discuss comments. Note to RFC Editor Replace Reference 3 (RFC 2234) with a reference to RFC 4234. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Dec 22 19:50:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epb8g-0003vF-5k; Thu, 22 Dec 2005 19:50:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epb8e-0003su-Pw; Thu, 22 Dec 2005 19:50:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27302; Thu, 22 Dec 2005 19:49:22 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpbBY-00015D-D9; Thu, 22 Dec 2005 19:53:29 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBN0n9w04834; Thu, 22 Dec 2005 16:49:09 -0800 (PST) Message-Id: <200512230049.jBN0n9w04834@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 22 Dec 2005 16:49:09 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 4317 on Session Description Protocol (SDP) Offer/Answer Examples X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4317 Title: Session Description Protocol (SDP) Offer/Answer Examples Author(s): A. Johnston, R. Sparks Status: Informational Date: December 2005 Mailbox: ajohnston@tello.com, rjsparks@estacado.net Pages: 24 Characters: 32262 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-offer-answer-examples-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4317.txt This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051222164754.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4317 --OtherAccess Content-Type: Message/External-body; name="rfc4317.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051222164754.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Fri Dec 23 15:31:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EptZI-0001JP-Uc; Fri, 23 Dec 2005 15:31:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EptZI-0001IY-1p for mmusic@megatron.ietf.org; Fri, 23 Dec 2005 15:31:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02853 for ; Fri, 23 Dec 2005 15:30:04 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EptcM-0007hs-UA for mmusic@ietf.org; Fri, 23 Dec 2005 15:34:24 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62889 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1EptZ7-0006fJ-HR for mmusic@ietf.org; Fri, 23 Dec 2005 20:31:01 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16B450DC-78EC-4FAB-84EE-595B03804E0B@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 23 Dec 2005 20:30:58 +0000 To: IETF MMUSIC working group X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Fwd: I-D ACTION:draft-walsh-mmusic-img-envelope-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org This is relevant to MMUSIC. Colin Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 20 December 2005 20:50:01 GMT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-walsh-mmusic-img-envelope-04.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The IMG Envelope > Author(s) : R. Walsh, et al. > Filename : draft-walsh-mmusic-img-envelope-04.txt > Pages : 34 > Date : 2005-12-20 > > This document defines the metadata transfer envelope for Internet > Media Guides (IMGs). IMG metadata describes files, resources and > multimedia programs available for streaming or downloading via > multicast or unicast. IMG metadata is encapsulated into, or > associated with, an IMG envelope before actual transport. The IMG > envelope is a structure providing independence between IMG > transport > protocols and different metadata formats. This specification > provides the IMG envelope instantiation using structured Extensible > Markup Language (XML) syntax, both as a wrapper in which to > embed an > IMG metadata object and as a distinct object to associate with a > distinct IMG metadata object. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-walsh-mmusic-img- > envelope-04.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Dec 23 15:31:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EptZq-0001d5-PZ; Fri, 23 Dec 2005 15:31:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EptZo-0001Z3-Pe for mmusic@megatron.ietf.org; Fri, 23 Dec 2005 15:31:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02988 for ; Fri, 23 Dec 2005 15:30:37 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eptcu-0007jF-PN for mmusic@ietf.org; Fri, 23 Dec 2005 15:34:57 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62889 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1EptZf-0006fJ-KH for mmusic@ietf.org; Fri, 23 Dec 2005 20:31:35 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <634E46E6-3118-4A0E-B695-43C8B567C9CA@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 23 Dec 2005 20:31:34 +0000 To: IETF MMUSIC working group X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Fwd: I-D ACTION:draft-greifenberg-mmusic-img-urn-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org This is relevant to MMUSIC. Colin Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 15 December 2005 20:50:02 GMT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-greifenberg-mmusic-img-urn-01.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Identifiers for Internet Media Guides (IMG) > Author(s) : J. Greifenberg > Filename : draft-greifenberg-mmusic-img-urn-01.txt > Pages : 10 > Date : 2005-12-15 > > This document defines a Uniform Resource Name (URN) namespace for > identifying Internet Media Guides (IMGs). IMG metadata describes > files, resources and multimedia programs available for streaming or > downloading via multicast or unicast. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-greifenberg-mmusic-img- > urn-01.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Dec 26 15:30:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eqyzj-0000HV-C8; Mon, 26 Dec 2005 15:30:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eqyzh-0000HL-25 for mmusic@megatron.ietf.org; Mon, 26 Dec 2005 15:30:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00031 for ; Mon, 26 Dec 2005 15:29:48 -0500 (EST) Message-Id: <200512262029.PAA00031@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eqz3O-0003ok-SX for mmusic@ietf.org; Mon, 26 Dec 2005 15:34:47 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eqyzd-000KU1-Qm; Mon, 26 Dec 2005 20:30:53 +0000 To: lennox@cs.columbia.edu, csp@csperkins.org Date: Mon, 26 Dec 2005 12:30:53 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mmusic@ietf.org, mankin@psg.com Subject: [MMUSIC] Need text for a sub-registry in comedia-tls X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org Jonathan, I haven't seen you propose text for the hash-func sub-registry, and time's a flying. I see no reason other than the sub-registry not to put comedia-tls on the January 5 IESG agenda. (Since comedia-tls is a normative reference for the two BFCP documents, we should definitely keep comedia-tls moving). Could you propose text before January 3? A resubmitted internet-draft is NOT needed, I will us a Note to the RFC Editor, so just send your proposed text it to this list as early as you can, so that there can be list consideration as well. If you would like me to propose this text, let me know. I can do so on the 1st when I return from some travel. Thanks, Allison ------- Forwarded Message Date: Tue, 13 Dec 2005 11:18:21 -0500 From: Russ Housley Subject: Re: comedia-tls iana considerations (was Re: [MMUSIC] Re: Progressing/ Resolving the IESG Review of the BFCP specs) Correct. At 11:02 AM 12/13/2005, Colin Perkins wrote: >Allison, > >[cc'ing Jonathan Lennox, to ensure this doesn't get lost] > >To confirm: you're proposing an update to comedia-tls IANA >considerations, not to sdp-bfcp? > >Colin > > > > >On 12 Dec 2005, at 20:49, Allison Mankin wrote: >>Thanks to Russ and Ted for the prompt re-review of the BFCP documents. >> >>Russ wrote: >>>This document depends on the fingerprint Attribute definition in >>>[10], which is draft-ietf-mmusic-comedia-tls-05. The definition of >>>the fingerprint attribute includes: >> >> hash-func = "sha-1" / "sha-224" / "sha-256" / >> "sha-384" / "sha-512" / >> "md5" / "md2" / token >> ; Additional hash functions can only >>come >> ; from updates to RFC 3279 >> >>>RFC 3279 does not define the short strings used here. RFC 3279 >>>provides ASN.1 object identifiers, which are not suitable >>>here. draft-ietf-mmusic-comedia-tls needs to say how these >>>identifiers will be assigned. Will IANA maintain a registry? >> >>Good point. I'll note to the WG that Russ also sent this to the IESG >>as a Last Call comment on the document. >> >>There are some instances when attribute values are registered in IANA, >>not just the att-field. One that is comparable is the key management >>protocol identifier from draft-ietf-mmusic-kmgmt-ext. >> >>So a suggestion is to add to the IANA Considerations a crisp new >>sub-registry for the hash-func values in the fingerprint attribute. >>Its rules for registration can be that new identifiers are >>permitted only for hash functions found in RFC 3279 or updates >>of RFC 3279. >> >>Does the editor want to propose some IANA Considerations text? >> >>Allison (wearing the hat of an AD shepherd for comedia-tls) >> >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic > ------- End of Forwarded Message _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Dec 27 10:49:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErH4w-0007DW-SO; Tue, 27 Dec 2005 10:49:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErH4v-0007DQ-CO for mmusic@megatron.ietf.org; Tue, 27 Dec 2005 10:49:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03681 for ; Tue, 27 Dec 2005 10:48:23 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErH8l-0000Yh-6P for mmusic@ietf.org; Tue, 27 Dec 2005 10:53:33 -0500 Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jBRFkGQw019047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Dec 2005 10:49:27 -0500 (EST) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.3/8.13.3) with ESMTP id jBRFkGkr064445; Tue, 27 Dec 2005 10:46:16 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.3/8.13.3/Submit) id jBRFkGI8064442; Tue, 27 Dec 2005 10:46:16 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17329.25032.486592.480141@cnr.cs.columbia.edu> Date: Tue, 27 Dec 2005 10:46:16 -0500 To: mankin@psg.com In-Reply-To: <200512262030.jBQKUtQw006890@cs.columbia.edu> References: <200512262030.jBQKUtQw006890@cs.columbia.edu> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: csp@csperkins.org, mmusic@ietf.org Subject: [MMUSIC] Re: Need text for a sub-registry in comedia-tls X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org On Monday, December 26 2005, "Allison Mankin" wrote to "lennox@cs.columbia.edu, csp@csperkins.org, mankin@psg.com, mmusic@ietf.org" saying: > Jonathan, > > I haven't seen you propose text for the hash-func sub-registry, > and time's a flying. I see no reason other than the > sub-registry not to put comedia-tls on the January 5 > IESG agenda. (Since comedia-tls is a normative reference > for the two BFCP documents, we should definitely keep > comedia-tls moving). > > Could you propose text before January 3? > A resubmitted internet-draft is NOT needed, I will us > a Note to the RFC Editor, so just send your proposed text > it to this list as early as you can, so that there can > be list consideration as well. > > If you would like me to propose this text, let me know. > I can do so on the 1st when I return from some travel. I sent a response asking if it would be useful for the hash function textual name registry needed to be more broadly defined, but since I got no response, I'll proceed with the appropriate text scoped just to comedia-tls. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic