From magnus.westerlund@ericsson.com Mon May 2 01:44:43 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF677E06F2; Mon, 2 May 2011 01:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXk48fCui8wW; Mon, 2 May 2011 01:44:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AAFEBE0655; Mon, 2 May 2011 01:44:41 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-c5-4dbe6ef8fb1c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 27.84.28525.8FE6EBD4; Mon, 2 May 2011 10:44:40 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 2 May 2011 10:44:40 +0200 Message-ID: <4DBE6EF7.3050709@ericsson.com> Date: Mon, 2 May 2011 10:44:39 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mykyta Yevstifeyev References: <20110428160138.13587.58242.idtracker@ietfa.amsl.com> <4DB9A26C.9010303@gmail.com> <4DBA7B11.8080708@ericsson.com> <4DBAE17E.6050807@gmail.com> In-Reply-To: <4DBAE17E.6050807@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-mmusic-ice-options-registry@tools.ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (IANA Registry for Interactive Connectivity Establishment (ICE) Options) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 08:44:43 -0000 Hi, When the last call has ended I will update the draft with the changes identified. Mykyta Yevstifeyev skrev 2011-04-29 18:04: > Magnus, > > 29.04.2011 11:47, Magnus Westerlund wrote: >> Hi Mykyta, >> >> Thanks for the review. >> >> See inline for response. >> >> Mykyta Yevstifeyev skrev 2011-04-28 19:22: >>> Hello, >>> >>> Some comments on this document, currently in Last Call. >>> >>>> Network Working Group M. Westerlund >>>> Internet-Draft Ericsson >>>> Updates: 5245 (if approved) C. Perkins >>>> Intended status: Standards Track University of Glasgow >>>> Expires: September 29, 2011 March 28, 2011 >>> I don't see why the intended status for this document is Standards >>> Track. Wouldn't Informational be enough? Could you please justify why >>> have you chosen it? >> I don't think we have put much thought into it. But one reason I can >> think of is to have it on the same maturity level as the ICE >> specification itself. Thus enabling a merge of this registry into an >> update of RFC 5245 without forcing it to be recycled as proposed. > This is a good reason, so I'll agree with it. Ok >>> Your registry description does not mention what is the precise name of >>> the registry. While everybody understands that is sands for ICE >>> options, it would be useful to give IANA distinctive guidelines on its >>> name (this is also required in RFC5226, Section 4.2, 1) in the list; >>> http://tools.ietf.org/html/rfc5226#section-4.2). >> >> Yes, I agree that it should be included in Section 3.1 of our document >> rather than only in the title which says "Interactive Connectivity >> Establishment (ICE) Options" > Agreed on this. Such name is fine, IMO. Ok >>> From RFC 5226, also Section 4.2: >>> >>>> 5) Initial assignments and reservations. Clear instructions >>>> should be provided to identify any initial assignments or >>>> registrations. In addition, any ranges that are to be reserved >>>> for "Private Use", "Reserved", "Unassigned", etc. should be >>>> clearly indicated. >>> Are there any initial assignments? Your document mentions one option; >>> shouldn't it be registered? >> No, because when draft-ietf-avtcore-rtp-ecn gets published that will >> actually do the registration. As that document isn't approved yet and in >> fact still not WG last called this registry will first be created empty >> and then populated. > So you should have mentioned this in the draft as well. Ok, will clarify. >>>> A registration request MUST include the following information: >>>> >>>> [ . . . ] >>> Shall this be mentioned as a registration template? >> It isn't written as one. It is a list of what needs to be present in the >> registration. And I think a template would be more focused on what needs >> to the general categories rather than the information. Thus I don't want >> this as registration template. > OK, this matter is not very important. >>>> o Email and Address of the Contact person >>> I think you should add the name of the contact person to the name of >>> this field as well. >> As the two first bullets are: >> >> o Name of contact person for the registration >> >> o Email and Address of the Contact person >> >> I don't quite understand your comment. Do you want us to merge the two >> entries? This as the contact persons will need to provide name, email >> and address. I am fine with merging them and this is likely a slight >> improvement. > No, I didn't propose to merge it. I just proposed to rename this field > as "Name, Email and Addresses of the Contact Person". I think it is logical to have only one entry saying: "Name, Email and Addresses of the Contact Person for the registration" Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From evnikita2@gmail.com Mon May 2 04:22:02 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33CE0709; Mon, 2 May 2011 04:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.17 X-Spam-Level: X-Spam-Status: No, score=-5.17 tagged_above=-999 required=5 tests=[AWL=-1.571, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRoQXxDzDFIe; Mon, 2 May 2011 04:22:01 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CDE9FE0682; Mon, 2 May 2011 04:22:00 -0700 (PDT) Received: by bwz13 with SMTP id 13so5291830bwz.31 for ; Mon, 02 May 2011 04:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NL1AqkBA0eExr0orTPoXeQMcF50Y1TjPf89ojVgrDpk=; b=Sk7OcuPhZf3F346YjUe0BrTWGJ7NB0QaoZzITmxN7uWCby4TyIolG2BeHVogk+IBBI rf1vbIuMnHqinRI2Mk1TvWn9vHQa3cpmXHyVRlUfEolhfIHgLKWqOd/alAxBVGNEDNa7 0mH6uCOOpfgcad53uwqw2eopag/maPpXuKQ7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=TXhvGSApKG5eXQ32h4A2qilCe2DPb7vVq5uGFe3FXoZ0IVj3DV0H+qiTVfJacQRbU9 7+iMExj8fIXDKgTmiYCftHxoPu5FsLlrRLat9OpqRfRg3vyuSdv5GJp1xeiz6NDV6pyl WimRpMpg4jtZGP2lN6cJmAyY1E0JI+OtGIx7o= Received: by 10.223.24.134 with SMTP id v6mr1198635fab.146.1304335318341; Mon, 02 May 2011 04:21:58 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id n7sm1727146fam.11.2011.05.02.04.21.56 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 04:21:57 -0700 (PDT) Message-ID: <4DBE93FE.2030405@gmail.com> Date: Mon, 02 May 2011 14:22:38 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Magnus Westerlund References: <20110428160138.13587.58242.idtracker@ietfa.amsl.com> <4DB9A26C.9010303@gmail.com> <4DBA7B11.8080708@ericsson.com> <4DBAE17E.6050807@gmail.com> <4DBE6EF7.3050709@ericsson.com> In-Reply-To: <4DBE6EF7.3050709@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 02 May 2011 05:17:00 -0700 Cc: "draft-ietf-mmusic-ice-options-registry@tools.ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (IANA Registry for Interactive Connectivity Establishment (ICE) Options) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 11:22:02 -0000 02.05.2011 11:44, Magnus Westerlund wrote: > Hi, > > When the last call has ended I will update the draft with the changes > identified. Thanks for considering and intention to incorporate my comments. Mykyta Yevstifeyev > Mykyta Yevstifeyev skrev 2011-04-29 18:04: >> Magnus, >> >> 29.04.2011 11:47, Magnus Westerlund wrote: >>> Hi Mykyta, >>> >>> Thanks for the review. >>> >>> See inline for response. >>> >>> Mykyta Yevstifeyev skrev 2011-04-28 19:22: >>>> Hello, >>>> >>>> Some comments on this document, currently in Last Call. >>>> >>>>> Network Working Group M. Westerlund >>>>> Internet-Draft Ericsson >>>>> Updates: 5245 (if approved) C. Perkins >>>>> Intended status: Standards Track University of Glasgow >>>>> Expires: September 29, 2011 March 28, 2011 >>>> I don't see why the intended status for this document is Standards >>>> Track. Wouldn't Informational be enough? Could you please justify why >>>> have you chosen it? >>> I don't think we have put much thought into it. But one reason I can >>> think of is to have it on the same maturity level as the ICE >>> specification itself. Thus enabling a merge of this registry into an >>> update of RFC 5245 without forcing it to be recycled as proposed. >> This is a good reason, so I'll agree with it. > Ok > >>>> Your registry description does not mention what is the precise name of >>>> the registry. While everybody understands that is sands for ICE >>>> options, it would be useful to give IANA distinctive guidelines on its >>>> name (this is also required in RFC5226, Section 4.2, 1) in the list; >>>> http://tools.ietf.org/html/rfc5226#section-4.2). >>> Yes, I agree that it should be included in Section 3.1 of our document >>> rather than only in the title which says "Interactive Connectivity >>> Establishment (ICE) Options" >> Agreed on this. Such name is fine, IMO. > Ok > >>>> From RFC 5226, also Section 4.2: >>>> >>>>> 5) Initial assignments and reservations. Clear instructions >>>>> should be provided to identify any initial assignments or >>>>> registrations. In addition, any ranges that are to be reserved >>>>> for "Private Use", "Reserved", "Unassigned", etc. should be >>>>> clearly indicated. >>>> Are there any initial assignments? Your document mentions one option; >>>> shouldn't it be registered? >>> No, because when draft-ietf-avtcore-rtp-ecn gets published that will >>> actually do the registration. As that document isn't approved yet and in >>> fact still not WG last called this registry will first be created empty >>> and then populated. >> So you should have mentioned this in the draft as well. > Ok, will clarify. > >>>>> A registration request MUST include the following information: >>>>> >>>>> [ . . . ] >>>> Shall this be mentioned as a registration template? >>> It isn't written as one. It is a list of what needs to be present in the >>> registration. And I think a template would be more focused on what needs >>> to the general categories rather than the information. Thus I don't want >>> this as registration template. >> OK, this matter is not very important. >>>>> o Email and Address of the Contact person >>>> I think you should add the name of the contact person to the name of >>>> this field as well. >>> As the two first bullets are: >>> >>> o Name of contact person for the registration >>> >>> o Email and Address of the Contact person >>> >>> I don't quite understand your comment. Do you want us to merge the two >>> entries? This as the contact persons will need to provide name, email >>> and address. I am fine with merging them and this is likely a slight >>> improvement. >> No, I didn't propose to merge it. I just proposed to rename this field >> as "Name, Email and Addresses of the Contact Person". > I think it is logical to have only one entry saying: > > "Name, Email and Addresses of the Contact Person for the registration" > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From miguel.a.garcia@ericsson.com Tue May 3 23:17:43 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A64E072A for ; Tue, 3 May 2011 23:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ug5ykOL-zuW for ; Tue, 3 May 2011 23:17:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DAF2AE0651 for ; Tue, 3 May 2011 23:17:42 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-ea-4dc0ef85b256 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DA.A4.28525.58FE0CD4; Wed, 4 May 2011 08:17:41 +0200 (CEST) Received: from [159.107.24.232] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 4 May 2011 08:17:40 +0200 Message-ID: <4DC0EF84.4090502@ericsson.com> Date: Wed, 4 May 2011 08:17:40 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] MMUSIC milestones updated X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 06:17:43 -0000 The MMUSIC milestones have been updated. http://datatracker.ietf.org/wg/mmusic/charter/ They are essentially the same milestones that we sent to the list on an e-mail on 13th of April, with the addition of a new milestone for the IANA registration of 'image' media type in SDP, which is set in August 2011, although we expect this draft to proceed faster than that. Miguel and Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From internet-drafts@ietf.org Wed May 4 21:28:12 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F966E084C; Wed, 4 May 2011 21:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.528 X-Spam-Level: X-Spam-Status: No, score=-103.528 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRmZLBA3YWGY; Wed, 4 May 2011 21:28:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C51E0697; Wed, 4 May 2011 21:28:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110505042811.4836.87420.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 21:28:11 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 04:28:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : SDP: Session Description Protocol Author(s) : Mark Handley Van Jacobson Colin Perkins Ali Begen Filename : draft-ietf-mmusic-rfc4566bis-03.txt Pages : 49 Date : 2011-05-04 This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-03.txt From abegen@cisco.com Wed May 4 21:35:35 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD68E084E for ; Wed, 4 May 2011 21:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.591 X-Spam-Level: X-Spam-Status: No, score=-10.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZT875A6VwA5 for ; Wed, 4 May 2011 21:35:34 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id D22AAE06AC for ; Wed, 4 May 2011 21:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=620; q=dns/txt; s=iport; t=1304570134; x=1305779734; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=xB4hxqM1vuIpBEWD2nltlwmy8oEWdZJ6BagoeXhcrsQ=; b=HDNNm6uArQgs77Gp0eyeNFpexK+sgenim0h+KVoi8PzwIPBFDfuJdkni no/qgEi3jVZgJzPUvh/7GNem6lcoeNQg2rs+LAs/XFsg/S9QOo2gR/kAg wrAcBoFfcmBZ3NXJO7oAfvHiI2QoJZbrSeOCxcloUzy1DWbzi/qMu1U22 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGUowk2rRDoG/2dsb2JhbACmInenMYEdniKGBwSGNI05ij4 X-IronPort-AV: E=Sophos;i="4.64,318,1301875200"; d="scan'208";a="350716728" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 05 May 2011 04:35:34 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p454ZYeV027173 for ; Thu, 5 May 2011 04:35:34 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 May 2011 21:35:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 May 2011 21:35:18 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EF50EBF@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4566bis revision Thread-Index: AcwK3U2akUKSnm1zQAy3Vrans9aemA== From: "Ali C. Begen (abegen)" To: "mmusic" X-OriginalArrivalTime: 05 May 2011 04:35:34.0513 (UTC) FILETIME=[DFC43610:01CC0ADD] Subject: [MMUSIC] 4566bis revision X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 04:35:35 -0000 I submitted a new version for 4566bis. Diff is available here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc4566bis-03 The major changes were updating the references and example = unicast/multicast addresses per the new guidelines. I did not change the = boilerplate (copyright stuff) but idnits complains about it. Any = objections to change it to the current/latest version? Or should it stay = that way? Another idnits complaint is normatively referencing RFC 2327. I guess we = could remove it to informative part as 4566 will appear in the normative = references section now. -acbegen From chimura730@oki.com Thu May 5 20:32:58 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8835AE0718 for ; Thu, 5 May 2011 20:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWXNUgOmyjnK for ; Thu, 5 May 2011 20:32:57 -0700 (PDT) Received: from gwf2.oki.co.jp (gwf2.oki.co.jp [202.226.91.187]) by ietfa.amsl.com (Postfix) with ESMTP id B1EC6E06F4 for ; Thu, 5 May 2011 20:32:57 -0700 (PDT) Received: by gwf2.oki.co.jp (Postfix, from userid 0) id 83C0CCF995; Fri, 6 May 2011 12:32:58 +0900 (JST) Received: from s111h119.dm1.oii.oki.co.jp [172.26.101.119] by gwf2.oki.co.jp with ESMTP id NAA04645; Fri, 6 May 2011 12:32:58 +0900 Received: from s111h119.dm1.oii.oki.co.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7B307398005; Fri, 6 May 2011 12:32:56 +0900 (JST) Received: from s24c46.dm1.oii.oki.co.jp (s24c46.dm1.oii.oki.co.jp [172.26.76.96]) by s111h119.dm1.oii.oki.co.jp (Postfix) with ESMTP id 67EE9398003; Fri, 6 May 2011 12:32:56 +0900 (JST) Received: from PC17099 (t102l39.dm1.oii.oki.co.jp [10.55.78.39]) by s24c46.dm1.oii.oki.co.jp (Postfix) with ESMTP id 4877B30F3F3; Fri, 6 May 2011 12:32:56 +0900 (JST) From: "Yasubumi CHIMURA" To: References: Date: Fri, 6 May 2011 12:32:56 +0900 Message-ID: <4A202199EF6C47CA9A11C3A085E03789@power.oki.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Thread-Index: AcwHaNIcWbal7zdbRMWAOQ9cdboSjQEK1b0Q In-Reply-To: Cc: keith.drage@alcatel-lucent.com, 'Yasubumi CHIMURA' Subject: Re: [MMUSIC] mmusic Digest, Vol 84, Issue 30 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 03:32:58 -0000 Dear Gonzalo, Folks, I'm Yasubumi Chimura of Oki Electric Industry and CIAJ in Japan. We have been discussed about "image/SDP" issue of T.38 in Japan. Thank you for your work about this draft. I hope to early assign RFC number for this draft, RFC4566bis will be refer it. Best Regards, Yasu >Date: Sat, 30 Apr 2011 14:07:53 -0400 >From: Gonzalo Salgueiro >To: mmusic >Cc: "DRAGE, Keith \(Keith\)" >Subject: Re: [MMUSIC] Notification for > draft-salgueiro-mmusic-image-iana-registration-00 >Message-ID: <99AD85AE-F2BE-4713-A196-6B1B97994F84@cisco.com> >Content-Type: text/plain; charset="us-ascii" > >I've submitted an -01 version that addresses all the comments raised thus far >as well as a few additional nits. > >Feedback welcome. > >Warm Regards, > >Gonzalo > >On Apr 28, 2011, at 1:34 PM, Gonzalo Salgueiro wrote: > >> Good point Keith. I prematurely figured that if 2119 language appeared ANYWHERE >>in the text, then the reference to it should be there. As you rightly point >>out, if it is in quoted text, there is likely no need for it. I'll verify and >>address this as appropriate. >> >> Warm regards, >> >> Gonzalo >> >> On Apr 28, 2011, at 6:06 AM, DRAGE, Keith (Keith) wrote: >> >>> But then there is no RFC 2119 language used in the document, except for >>>extracted text (with associated references) from other documents, where the >>>conventions in those other documents have to apply, rather than the ones in >>>this document. >>> >>> Check with the RFC editor on the need for the 2119 boilerplate when no such >>>usage is made. >>> >>> Regards >>> >>> Keith >>> >>> From: Gonzalo Salgueiro [mailto:gsalguei@cisco.com] >>> Sent: 27 April 2011 17:51 >>> To: DRAGE, Keith (Keith) >>> Cc: mmusic; Flemming Andreasen >>> Subject: Re: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-00 >>> >>> Many thanks for the feedback Keith. >>> >>> If we think there is value in making things a bit more brief by removing the references to RFC 5226 and the SDP media type registry, then I can certainly accommodate that. >>> >>> FYI - The reference to RFC 2119 is in Section 1. >>> >>> Warm Regards, >>> >>> Gonzalo >>> >>> On Apr 27, 2011, at 9:57 AM, DRAGE, Keith (Keith) wrote: >>> >>> >>> Section 3 >>> >>> This document registers with IANA the 'image' media type in the >>> Session Description Protocol (SDP) Parameters registry [SDP-IANA] in >>> accordance with the "Standards Action" policy defined in Section 4.1 >>> of [RFC5226]. >>> >>> >>> From the perspective of brevity, I do not believe the reference to RFC 5226 is necessary. IANA will apply the policy stated in the table, which now exists, rather than anything that is said in this RFC. I also do not believe you need the [SDP-IANA] reference. If you put the full stop after "registry" you have clearly identified the table to IANA. >>> >>> This document registers with IANA the 'image' media type in the >>> Session Description Protocol (SDP) Parameters registry. >>> >>> References >>> >>> RFC 2119 is never used as a reference. Delete. >>> >>> Otherwise the document looks good to me. >>> >>> Regards >>> >>> Keith >>> >>> ________________________________________ >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro >>> Sent: 26 April 2011 19:28 >>> To: mmusic >>> Cc: Flemming Andreasen >>> Subject: [MMUSIC] Notification for draft-salgueiro-mmusic-image-iana-registration-00 >>> >>> Folks, >>> >>> In reference to some discussion we had on the list recently, I wanted to bring your attention to an Internet Draft I submitted that registers 'image' in the newly created SDP media type registry. For some reason (unbeknownst to me) this was omitted in RFC 4566 when the other media types were registered. This draft aims to rectify that oversight. >>> >>> The draft can be found at: >>> >>> http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-registration-00 >>> >>> I would welcome any comments on the draft. >>> >>> Warm Regards, >>> >>> Gonzalo From miguel.a.garcia@ericsson.com Mon May 9 00:04:05 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99FE06C7 for ; Mon, 9 May 2011 00:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGbH3u+YA1OZ for ; Mon, 9 May 2011 00:04:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 972DCE06A3 for ; Mon, 9 May 2011 00:04:03 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-e5-4dc791e27550 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F8.AA.28525.2E197CD4; Mon, 9 May 2011 09:04:02 +0200 (CEST) Received: from [159.107.24.228] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 9 May 2011 09:04:01 +0200 Message-ID: <4DC791E0.7010908@ericsson.com> Date: Mon, 9 May 2011 09:04:00 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen , 'Yasubumi CHIMURA' Subject: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 07:04:05 -0000 In relation with the registration of the SDP 'image' media type, we are going to try to expedite this draft, since it is a very simple missing registration. The idea is to progress the draft as an individual submission, AD-sponsored draft. So, the chairs would like the working group to take a closer look at it (it is a short one), so that we can go to WGLC in a short time frame. So please, send comments as soon as possible. Do not wait to the WGLC. BR, Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From keith.drage@alcatel-lucent.com Mon May 9 08:51:12 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BCCE080B for ; Mon, 9 May 2011 08:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.764 X-Spam-Level: X-Spam-Status: No, score=-105.764 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w2PGDjC9D9M for ; Mon, 9 May 2011 08:51:11 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id B8145E0807 for ; Mon, 9 May 2011 08:51:09 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p49Foxr0024476 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 May 2011 17:50:59 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 9 May 2011 17:50:59 +0200 From: "DRAGE, Keith (Keith)" To: "Miguel A. Garcia" , mmusic Date: Mon, 9 May 2011 17:50:58 +0200 Thread-Topic: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration Thread-Index: AcwOF1IVPPtmsmsTRKyvnGcc+ykR6gASV9Cw Message-ID: References: <4DC791E0.7010908@ericsson.com> In-Reply-To: <4DC791E0.7010908@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Flemming Andreasen , 'Yasubumi CHIMURA' Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 15:51:12 -0000 If you are going to WGLC this document, surely you might as well make this = a working group draft.=20 If it is AD sponsored, then the first question is sufficient - look at it n= ow, and then it goes for a four week IETF last call. Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Miguel A. Garcia > Sent: 09 May 2011 08:04 > To: mmusic > Cc: Flemming Andreasen; 'Yasubumi CHIMURA' > Subject: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana- > registration >=20 > In relation with the registration of the SDP 'image' media type, we are > going to try to expedite this draft, since it is a very simple missing > registration. >=20 > The idea is to progress the draft as an individual submission, > AD-sponsored draft. So, the chairs would like the working group to take a > closer look at it (it is a short one), so that we can go to WGLC in a > short time frame. >=20 > So please, send comments as soon as possible. Do not wait to the WGLC. >=20 > BR, >=20 > Miguel > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From Bert.Greevenbosch@huawei.com Mon May 9 19:05:13 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C07BE06D6 for ; Mon, 9 May 2011 19:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waetrygGyQP4 for ; Mon, 9 May 2011 19:05:12 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC02E06F1 for ; Mon, 9 May 2011 19:05:12 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKY00BJZJ1ELC@szxga04-in.huawei.com> for mmusic@ietf.org; Tue, 10 May 2011 10:03:14 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKY00BDCJ1EP8@szxga04-in.huawei.com> for mmusic@ietf.org; Tue, 10 May 2011 10:03:14 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 10 May 2011 10:03:11 +0800 Received: from SZXEML501-MBS.china.huawei.com ([169.254.1.142]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 10 May 2011 10:03:11 +0800 Date: Tue, 10 May 2011 02:03:09 +0000 From: Bert Greevenbosch X-Originating-IP: [10.70.109.52] To: "mmusic@ietf.org" Message-id: <46A1DF3F04371240B504290A071B4DB6012C9739@SZXEML501-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_pAbvuLDBWSBABChfIErmkQ)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: Question on unknown attributes in SDP offer/answer Thread-index: AcwOtmkZFU6Yd/DzREOAXyjmslhSwQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [MMUSIC] Question on unknown attributes in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 02:05:13 -0000 --Boundary_(ID_pAbvuLDBWSBABChfIErmkQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, I have a question for the SDP offer/answer model experts. It is related to the "3dFormat" attribute draft (http://tools.ietf.org/id/draft-greevenbosch-mmusic-signal-3d-format-00.txt). The issue has been touched before, but more in the context of frame packing. The current issue concerns how a legacy device will treat the for it unknown "3dFormat" attribute, especially in SIP negotiation. I have found the following related info: * The SDP spec (RFC 4566) defines that unknown attributes MUST be ignored: "If an attribute is received that is not understood, it MUST be ignored by the receiver." (section 5.13) * The SDP offer/answer spec (RFC 3264) gives no information about what to do with unknown attributes. The spec does not say whether the answerer can/will omit unknown attributes in its answer. * The SIP spec (RFC 3261) specifies a warning code 306 "Attribute not understood: One or more of the media attributes in the session description are not supported.". It does not mandate using this warning code, or specify whether it can be used with a SIP 200 OK response. Ideal would be, when the answerer would omit SDP attributes it does not understand. In that case, the offerer can detect the client does not understand the "3dFormat" attribute and can update its offer. Does any of you know more about how it works in praxis? Is there an established way on how current implementations deal with unknown SDP attributes when doing SIP negotiation? Thanks a lot for your help! Best regards, Bert --Boundary_(ID_pAbvuLDBWSBABChfIErmkQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

I have a question for the SDP offer/answer model experts. It is related to the "3dFormat" attribute draft (http://tools.ietf.org/id/draft-greevenbosch-mmusic-signal-3d-format-00.txt).

 

The issue has been touched before, but more in the context of frame packing. The current issue concerns how a legacy device will treat the for it unknown "3dFormat" attribute, especially in SIP negotiation.

 

I have found the following related info:

 

·         The SDP spec (RFC 4566) defines that unknown attributes MUST be ignored:
"If an attribute is received that is not understood, it MUST be ignored by the receiver." (section 5.13)

·         The SDP offer/answer spec (RFC 3264) gives no information about what to do with unknown attributes. The spec does not say whether the answerer can/will omit unknown attributes in its answer.

·         The SIP spec (RFC 3261) specifies a warning code 306 "Attribute not understood: One or more of the media attributes in the session description are not supported.". It does not mandate using this warning code, or specify whether it can be used with a SIP 200 OK response.

 

Ideal would be, when the answerer would omit SDP attributes it does not understand. In that case, the offerer can detect the client does not understand the "3dFormat" attribute and can update its offer.

 

Does any of you know more about how it works in praxis? Is there an established way on how current implementations deal with unknown SDP attributes when doing SIP negotiation?

 

Thanks a lot for your help!

 

Best regards,

Bert

--Boundary_(ID_pAbvuLDBWSBABChfIErmkQ)-- From fandreas@cisco.com Mon May 9 19:06:49 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3434E0849; Mon, 9 May 2011 19:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkuWcGIjJNDZ; Mon, 9 May 2011 19:06:48 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 569B6E06F1; Mon, 9 May 2011 19:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=19036; q=dns/txt; s=iport; t=1304993208; x=1306202808; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=++nBtQZkll1Vf6OW/NJ3LpXK6Sj/EO/wblyvzCyIA+I=; b=D1N+n4euHoC1BPHY9c6eeQQfUE61OKKWxsN4NdI987J4+XSDBdTMeCiy 9EenHfICOjQ/ec8kBX7xDIg0UBP0GnhrasRZDz0QF6AR6vQz1Ri6+MUAE QO97UePJojwPxApVvX6+pGux+Xlf2q3B4Gdz1vX24w9tj5zHiPXXJQXma 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIacyE2tJV2Y/2dsb2JhbACCY6Mgd6dMnj2GDASPZI56 X-IronPort-AV: E=Sophos;i="4.64,343,1301875200"; d="scan'208,217";a="311994742" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 10 May 2011 02:06:47 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4A26kAM025353; Tue, 10 May 2011 02:06:46 GMT Message-ID: <4DC89DB6.70008@cisco.com> Date: Mon, 09 May 2011 22:06:46 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic References: <4DA86A44.9040909@cisco.com> In-Reply-To: <4DA86A44.9040909@cisco.com> Content-Type: multipart/alternative; boundary="------------080301010504070000000404" Cc: mmusic-chairs@ietf.org, draft-ietf-mmusic-ice-tcp@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 02:06:49 -0000 This is a multi-part message in MIME format. --------------080301010504070000000404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have not seen any comments on this document since the WGLC was issued. If anybody reviewed the document, but did not have any comments on it, please let us know. In any case, I have a few comments on the document: Non-Editorial: =========== - Section 7.1, third paragraph If the TCP connection cannot be established, the check is considered to have failed, and a full-mode agent MUST update the pair state to Failed in the check list. a) How long do you wait before determining it cannot be established ? Need some considerations around this. b) Also, how fast do you attempt to establish additional TCP connections ? Timer Ta considerations would seem to apply to the TCP connection establishment here. - Section 11.1 The section seems to be written under the assumption that both sides are full ICE Implementations. Need to consider lite implementations as well. - Section 12 I believe there is a TCP amplification attack similar to the STUN amplification attack that requires consideration, since the TCP connection is established prior to any STUN/ICE checks and involves TCP state creation on the part of the attacked party. - Section 13 I was surprised to see no IANA considerations since "TCP" is defined as a new transport-extension value here, however upon checking RFC 5245, there apparently is no registry defined for this. RFC 5245 Section 14 appears to indicate this was not an oversight at the time, however with ice-tcp, I think we should define a registry. Editorial/Nits ========== - Section 1: s/in as a broad/in as broad - Section 3, third paragraph server reflexive, NAT-assisted, tunneled, or relayed candidates of these three types Add reference to Section 5 for further explanation. - Section 3, Figure 1 It would be helpful to either expand the figure to cover the non-(D)TLS case as well or have another figure showing that for comparison - Section 4.2 s/local-preference/local preference/ for consistency with RFC 5245 (multiple occurrences) - Section 4.2 The direction-pref MUST be between 0 and 7, with 7 being the most preferred. The other-pref MUST be between 0 and 8191, with 8191 being the most preferred. Rephrase to make clear that 0 and 8191 (presumably) are both valid values in these ranges. - Section 4.3 If a media stream is inherently TCP-based, the agent MUST select an active candidate as the default. This ensures proper directionality of connection establishment for NAT traversal with non-ICE implementations. It doesn't ensure it, however under the assumption that the ICE endpoint is behind a NAT, it enhances the likelihood of the connection establishment succeeding. - Section 4.5 The connection-address and port encoded into the candidate attribute for active candidates MUST be set to the IP address that will be used for the attempt, but the port(s) MUST be set to 9 (i.e., Discard). - Delete the "and port" part. - Section 5, third paragraph If the local network or host does not support IPv6 addressing, then clients SHOULD make use of other techniques, e.g., Teredo [RFC4380] or SOCKS IPv4-IPv6 gatewaying [RFC3089], for obtaining IPv6 candidates. Add "TURN-IPV6 [RFC6156]" to the beginning of the example list. - Section 5, 4th paragraph For example, using multiple NAT-assisted techniques with the same NAT usually results only in redundant candidates and similarly out of multiple different UDP tunneling or relaying techniques with similar features using just one is often enough. Hard to read. Suggest breaking sentence in two ("...candidates. Similarly, out of..."). Regardless, I'm not sure exaclty what "similar features" implies here. An example would be good. - Section 5.3, last paragraph Should reference the PCP WG and ongoing work there as well. - Section 5.5, last paragraph It is also possible to use, e.g., an SSH [RFC4250] tunnel RFC 4251 would seem to be a better reference here. - Section 12 s/sips/SIPS [RFC3261]/ - Section 15.2 RFC 3261, 5389, 5766, and 6062 should all be normative rather informative. - Appendix A s/hand shake/handshake s/SYNACK/SYN-ACK - Please make sure to run id-nits check before submitting the update. Thanks -- Flemming On 4/15/11 11:54 AM, Flemming Andreasen wrote: > This is to announce a 2 week Working Group Last Call for > > draft-ietf-mmusic-ice-tcp-13 > > as Proposed Standard. Please review and provide any comments you may > have on the document before Monday, May 2nd, 2011. Comments should be > sent to the document authors and the MMUSIC WG list. > > > Thanks > > Flemming & Miguel > > > > Draft Info: > > Title : TCP Candidates with Interactive Connectivity Establishment (ICE) > Author(s) : J. Rosenberg, et al. > Filename : draft-ietf-mmusic-ice-tcp-13.txt > Pages : 29 > Date : 2011-04-11 > > Interactive Connectivity Establishment (ICE) defines a mechanism for > NAT traversal for multimedia communication protocols based on the > offer/answer model of session negotiation. ICE works by providing a > set of candidate transport addresses for each media stream, which are > then validated with peer-to-peer connectivity checks based on Session > Traversal Utilities for NAT (STUN). ICE provides a general framework > for describing candidates, but only defines UDP-based transport > protocols. This specification extends ICE to TCP-based media, > including the ability to offer a mix of TCP and UDP-based candidates > for a single stream. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-13.txt > > --------------080301010504070000000404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have not seen any comments on this document since the WGLC was issued. If anybody reviewed the document, but did not have any comments on it, please let us know.


In any case, I have a few comments on the document:


Non-Editorial:
===========
- Section 7.1, third paragraph
<quote>
   If the TCP connection cannot be established, the check is considered
   to have failed, and a full-mode agent MUST update the pair state to
   Failed in the check list.
</quote>
a) How long do you wait before determining it cannot be established ? Need some considerations around this.
b) Also, how fast do you attempt to establish additional TCP connections ? Timer Ta considerations would seem to apply to the TCP connection establishment here.

- Section 11.1
The section seems to be written under the assumption that both sides are full ICE Implementations. Need to consider lite implementations as well.

- Section 12
I believe there is a TCP amplification attack similar to the STUN amplification attack that requires consideration, since the TCP connection is established prior to any STUN/ICE checks and involves TCP state creation on the part of the attacked party. 

- Section 13
I was surprised to see no IANA considerations since "TCP" is defined as a new transport-extension value here, however upon checking RFC 5245, there apparently is no registry defined for this. RFC 5245 Section 14 appears to indicate this was not an oversight at the time, however with ice-tcp, I think we should define a registry. 




Editorial/Nits
==========
-  Section 1: s/in as a broad/in as broad

- Section 3, third paragraph
<quote> server reflexive, NAT-assisted, tunneled, or relayed candidates of these three types</quote>
Add reference to Section 5 for further explanation.

- Section 3, Figure 1
It would be helpful to either expand the figure to cover the non-(D)TLS case as well or have another figure showing that for comparison

- Section 4.2
s/local-preference/local preference/   for consistency with RFC 5245 (multiple occurrences)

- Section 4.2
<quote>
The direction-pref MUST be between 0 and 7, with 7 being the most
   preferred.  The other-pref MUST be between 0 and 8191, with 8191
   being the most preferred.
</quote>
Rephrase to make clear that 0 and 8191 (presumably) are both valid values in these ranges.

- Section 4.3
<quote>
   If a media stream is inherently TCP-based, the agent MUST select an
   active candidate as the default.  This ensures proper directionality
   of connection establishment for NAT traversal with non-ICE
   implementations.
</quote>
It doesn't ensure it, however under the assumption that the ICE endpoint is behind a NAT, it enhances the likelihood of the connection establishment succeeding.

- Section 4.5
<quote>
   The connection-address and port encoded into the candidate attribute
   for active candidates MUST be set to the IP address that will be used
   for the attempt, but the port(s) MUST be set to 9 (i.e., Discard).
</quote>
- Delete the "and port" part.


- Section 5, third paragraph
<quote>
If the local network or host
   does not support IPv6 addressing, then clients SHOULD make use of
   other techniques, e.g., Teredo [RFC4380] or SOCKS IPv4-IPv6
   gatewaying [RFC3089], for obtaining IPv6 candidates.
</quote>
Add "TURN-IPV6 [RFC6156]" to the beginning of the example list.


- Section 5, 4th paragraph
<quote>
For
   example, using multiple NAT-assisted techniques with the same NAT
   usually results only in redundant candidates and similarly out of
   multiple different UDP tunneling or relaying techniques with similar
   features using just one is often enough.
</quote>
Hard to read. Suggest breaking sentence in two ("...candidates.  Similarly, out of..."). Regardless, I'm not sure exaclty what "similar features" implies here. An example would be good.


- Section 5.3, last paragraph
Should reference the PCP WG and ongoing work there as well.


- Section 5.5, last paragraph
<quote>
It is also possible to use, e.g., an SSH [RFC4250] tunnel
</quote>
RFC 4251 would seem to be a better reference here.


- Section 12
s/sips/SIPS [RFC3261]/

- Section 15.2
RFC 3261, 5389, 5766, and 6062 should all be normative rather informative.

- Appendix A
s/hand shake/handshake
s/SYNACK/SYN-ACK

- Please make sure to run id-nits check before submitting the update.

Thanks

-- Flemming



On 4/15/11 11:54 AM, Flemming Andreasen wrote:
This is to announce a 2 week Working Group Last Call for

    draft-ietf-mmusic-ice-tcp-13

as Proposed Standard. Please review and provide any comments you may have on the document before Monday, May 2nd, 2011. Comments should be sent to the document authors and the MMUSIC WG list.


Thanks

    Flemming & Miguel



Draft Info:

 
	Title           : TCP Candidates with Interactive Connectivity Establishment (ICE)
	Author(s)       : J. Rosenberg, et al.
	Filename        : draft-ietf-mmusic-ice-tcp-13.txt
	Pages           : 29
	Date            : 2011-04-11

Interactive Connectivity Establishment (ICE) defines a mechanism for
NAT traversal for multimedia communication protocols based on the
offer/answer model of session negotiation.  ICE works by providing a
set of candidate transport addresses for each media stream, which are
then validated with peer-to-peer connectivity checks based on Session
Traversal Utilities for NAT (STUN).  ICE provides a general framework
for describing candidates, but only defines UDP-based transport
protocols.  This specification extends ICE to TCP-based media,
including the ability to offer a mix of TCP and UDP-based candidates
for a single stream.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-13.txt

--------------080301010504070000000404-- From miguel.a.garcia@ericsson.com Mon May 9 23:05:48 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D021E0780 for ; Mon, 9 May 2011 23:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9STDoDVhyyO for ; Mon, 9 May 2011 23:05:47 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E4C20E077B for ; Mon, 9 May 2011 23:05:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-d8-4dc8d233a99f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 32.2D.11171.332D8CD4; Tue, 10 May 2011 07:50:43 +0200 (CEST) Received: from [159.107.24.228] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 10 May 2011 07:50:43 +0200 Message-ID: <4DC8D232.8000501@ericsson.com> Date: Tue, 10 May 2011 07:50:42 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4DC791E0.7010908@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen , mmusic , 'Yasubumi CHIMURA' Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 06:05:48 -0000 Hi Keith, An individual document will not go through an official WGLC, but I guess the working group can always get a closer look at it before the author submitting it as an individual submission. /Miguel On 09/05/2011 17:50, DRAGE, Keith (Keith) wrote: > If you are going to WGLC this document, surely you might as well make this a working group draft. > > If it is AD sponsored, then the first question is sufficient - look at it now, and then it goes for a four week IETF last call. > > Keith > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Miguel A. Garcia >> Sent: 09 May 2011 08:04 >> To: mmusic >> Cc: Flemming Andreasen; 'Yasubumi CHIMURA' >> Subject: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana- >> registration >> >> In relation with the registration of the SDP 'image' media type, we are >> going to try to expedite this draft, since it is a very simple missing >> registration. >> >> The idea is to progress the draft as an individual submission, >> AD-sponsored draft. So, the chairs would like the working group to take a >> closer look at it (it is a short one), so that we can go to WGLC in a >> short time frame. >> >> So please, send comments as soon as possible. Do not wait to the WGLC. >> >> BR, >> >> Miguel >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From simon.perreault@viagenie.ca Tue May 10 06:08:20 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237CEE076E for ; Tue, 10 May 2011 06:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEH8Ux2j1O2j for ; Tue, 10 May 2011 06:08:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id A1E73E06D8 for ; Tue, 10 May 2011 06:08:03 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6e44:d070:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 74FF920D22 for ; Tue, 10 May 2011 09:08:00 -0400 (EDT) Message-ID: <4DC9389B.8000306@viagenie.ca> Date: Tue, 10 May 2011 09:07:39 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: mmusic@ietf.org References: <4DA86A44.9040909@cisco.com> <4DC89DB6.70008@cisco.com> In-Reply-To: <4DC89DB6.70008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 13:08:20 -0000 Flemming Andreasen wrote, on 05/09/2011 10:06 PM: > I have not seen any comments on this document since the WGLC was issued. If > anybody reviewed the document, but did not have any comments on it, please let > us know. I have reviewed the document multiple times in its lifetime. All my previous comments have been addressed. ICE TCP is needed not only for NAT traversal, but also for the transition to IPv6. This work is important and overdue. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From eckelcu@cisco.com Tue May 10 12:29:48 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA58FE06B9 for ; Tue, 10 May 2011 12:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FQCnmyP0xX0 for ; Tue, 10 May 2011 12:29:47 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 71399E069F for ; Tue, 10 May 2011 12:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2327; q=dns/txt; s=iport; t=1305055787; x=1306265387; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=zJmmDZfPstwk6KVayXMrYzCGpQCa6C96uWOurp0Nc10=; b=E5hGqQrCYS//scqSTsWMSuIgZ604l5COU30pYimoJENDhy7jkiqDxr6P nUofbWpq8WLDinhl6EpZv/PEK/tf5a4ARvmgGWAVIvLQWfT4rb96nck3I x/EKz+5dax1SVN0EV9/B1JNT0vTdpmF8QAKOtn0gauYh6ST6FUz31HyIS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBACeRyU2rRDoG/2dsb2JhbACXWo4wd6kGnjuGDwSGQo1eik4 X-IronPort-AV: E=Sophos;i="4.64,347,1301875200"; d="scan'208";a="445202458" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 10 May 2011 19:29:42 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4AJTgvx032145; Tue, 10 May 2011 19:29:42 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 12:29:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 May 2011 12:29:41 -0700 Message-ID: In-Reply-To: <46A1DF3F04371240B504290A071B4DB6012C9739@SZXEML501-MBS.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Question on unknown attributes in SDP offer/answer Thread-Index: AcwOtmkZFU6Yd/DzREOAXyjmslhSwQAkKg8A References: <46A1DF3F04371240B504290A071B4DB6012C9739@SZXEML501-MBS.china.huawei.com> From: "Charles Eckel (eckelcu)" To: "Bert Greevenbosch" , X-OriginalArrivalTime: 10 May 2011 19:29:42.0669 (UTC) FILETIME=[9C9FEBD0:01CC0F48] Subject: Re: [MMUSIC] Question on unknown attributes in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 19:29:49 -0000 Hi Bert, An end system that is producing an answer to an SDP offer that includes SDP attributes it does not understand should ignore those attributes and not include them within the answer. I find this to be done correctly by most implementations. Cheers, Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Bert Greevenbosch > Sent: Monday, May 09, 2011 7:03 PM > To: mmusic@ietf.org > Subject: [MMUSIC] Question on unknown attributes in SDP offer/answer >=20 > Hi all, >=20 >=20 >=20 > I have a question for the SDP offer/answer model experts. It is related to the "3dFormat" attribute > draft (http://tools.ietf.org/id/draft-greevenbosch-mmusic-signal-3d-format-00. txt). >=20 >=20 >=20 > The issue has been touched before, but more in the context of frame packing. The current issue > concerns how a legacy device will treat the for it unknown "3dFormat" attribute, especially in SIP > negotiation. >=20 >=20 >=20 > I have found the following related info: >=20 >=20 >=20 > * The SDP spec (RFC 4566) defines that unknown attributes MUST be ignored: > "If an attribute is received that is not understood, it MUST be ignored by the receiver." (section > 5.13) >=20 > * The SDP offer/answer spec (RFC 3264) gives no information about what to do with unknown > attributes. The spec does not say whether the answerer can/will omit unknown attributes in its answer. >=20 > * The SIP spec (RFC 3261) specifies a warning code 306 "Attribute not understood: One or more > of the media attributes in the session description are not supported.". It does not mandate using this > warning code, or specify whether it can be used with a SIP 200 OK response. >=20 >=20 >=20 > Ideal would be, when the answerer would omit SDP attributes it does not understand. In that case, the > offerer can detect the client does not understand the "3dFormat" attribute and can update its offer. >=20 >=20 >=20 > Does any of you know more about how it works in praxis? Is there an established way on how current > implementations deal with unknown SDP attributes when doing SIP negotiation? >=20 >=20 >=20 > Thanks a lot for your help! >=20 >=20 >=20 > Best regards, >=20 > Bert From miguel.a.garcia@ericsson.com Wed May 11 03:52:26 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A93E07B9 for ; Wed, 11 May 2011 03:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu8CcplzFVKb for ; Wed, 11 May 2011 03:52:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 361B4E0679 for ; Wed, 11 May 2011 03:52:25 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-28-4dca6a68881c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6D.E2.28525.86A6ACD4; Wed, 11 May 2011 12:52:24 +0200 (CEST) Received: from [159.107.24.228] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 11 May 2011 12:52:23 +0200 Message-ID: <4DCA6A67.10701@ericsson.com> Date: Wed, 11 May 2011 12:52:23 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <46A1DF3F04371240B504290A071B4DB6012C9739@SZXEML501-MBS.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Question on unknown attributes in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 10:52:26 -0000 Hi Bert, I agree with Charles, if an attribute present in the SDP offer is not understood, it will be simply ignored, and then the SDP answer will be produced. Notice that the attribute not only needs to be understood by the recipient of the SDP offer, but also by possible intermediaries that inspect SDP, most notably SBCs. I guess most SBCs allow operators to decide on what to do with unknown attributes, in which case you have the possibility of the attribute to be filtered by an SBC. /Miguel On 10/05/2011 21:29, Charles Eckel (eckelcu) wrote: > Hi Bert, > > An end system that is producing an answer to an SDP offer that includes > SDP attributes it does not understand should ignore those attributes and > not include them within the answer. I find this to be done correctly by > most implementations. > > Cheers, > Charles > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Bert Greevenbosch >> Sent: Monday, May 09, 2011 7:03 PM >> To: mmusic@ietf.org >> Subject: [MMUSIC] Question on unknown attributes in SDP offer/answer >> >> Hi all, >> >> >> >> I have a question for the SDP offer/answer model experts. It is > related to the "3dFormat" attribute >> draft > (http://tools.ietf.org/id/draft-greevenbosch-mmusic-signal-3d-format-00. > txt). >> >> >> >> The issue has been touched before, but more in the context of frame > packing. The current issue >> concerns how a legacy device will treat the for it unknown "3dFormat" > attribute, especially in SIP >> negotiation. >> >> >> >> I have found the following related info: >> >> >> >> * The SDP spec (RFC 4566) defines that unknown attributes MUST > be ignored: >> "If an attribute is received that is not understood, it MUST be > ignored by the receiver." (section >> 5.13) >> >> * The SDP offer/answer spec (RFC 3264) gives no information > about what to do with unknown >> attributes. The spec does not say whether the answerer can/will omit > unknown attributes in its answer. >> >> * The SIP spec (RFC 3261) specifies a warning code 306 > "Attribute not understood: One or more >> of the media attributes in the session description are not > supported.". It does not mandate using this >> warning code, or specify whether it can be used with a SIP 200 OK > response. >> >> >> >> Ideal would be, when the answerer would omit SDP attributes it does > not understand. In that case, the >> offerer can detect the client does not understand the "3dFormat" > attribute and can update its offer. >> >> >> >> Does any of you know more about how it works in praxis? Is there an > established way on how current >> implementations deal with unknown SDP attributes when doing SIP > negotiation? >> >> >> >> Thanks a lot for your help! >> >> >> >> Best regards, >> >> Bert > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ari.keranen@nomadiclab.com Wed May 11 08:56:01 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A18EE0811; Wed, 11 May 2011 08:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mu7HqhEnmCq; Wed, 11 May 2011 08:56:00 -0700 (PDT) Received: from gw.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id D115DE0659; Wed, 11 May 2011 08:55:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 497994E6DE; Wed, 11 May 2011 18:55:51 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsJAReRXjfWW; Wed, 11 May 2011 18:55:49 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id AE3814E6CF; Wed, 11 May 2011 18:55:49 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: <4DC89DB6.70008@cisco.com> Date: Wed, 11 May 2011 18:55:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <56FA6861-542E-422F-AEE2-5B987014E8A4@nomadiclab.com> References: <4DA86A44.9040909@cisco.com> <4DC89DB6.70008@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.1084) Cc: "mmusic-chairs@ietf.org" , mmusic , "draft-ietf-mmusic-ice-tcp@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 15:56:01 -0000 Hi Flemming, Thanks for the thorough review! See inline. On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote: [...] > - Section 7.1, third paragraph > > If the TCP connection cannot be established, the check is = considered > to have failed, and a full-mode agent MUST update the pair state to > Failed in the check list. > > a) How long do you wait before determining it cannot be established ? = Need some considerations around this I have considered this as an implementation/platform detail: you do = connect() and wait until it succeeds or fails. Or do you have = suggestions what additional to recommend here? > b) Also, how fast do you attempt to establish additional TCP = connections ? Timer Ta considerations would seem to apply to the TCP = connection establishment here.=20 Yes, the agents pace the start of the checks like for UDP. The end of = section 4.1 says "Like its UDP counterparts, TCP-based STUN transactions = are paced out at one every Ta seconds." It could be a bit confusing that = the comment is under "Gathering candidates" section, but it refers to = all STUN transactions. > - Section 11.1 > The section seems to be written under the assumption that both sides = are full ICE Implementations. Need to consider lite implementations as = well.=20 This seemed OK to me. What would you change here to accommodate also = lite agents? > - Section 12 > I believe there is a TCP amplification attack similar to the STUN = amplification attack that requires consideration, since the TCP = connection is established prior to any STUN/ICE checks and involves TCP = state creation on the part of the attacked party. =20 I guess you're right. We should document that, but any ideas for = mitigation? > - Section 13 > I was surprised to see no IANA considerations since "TCP" is defined = as a new transport-extension value here, however upon checking RFC 5245, = there apparently is no registry defined for this. RFC 5245 Section 14 = appears to indicate this was not an oversight at the time, however with = ice-tcp, I think we should define a registry. =20 Good point; we'll add one in the next revision. > Editorial/Nits > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - Section 1: s/in as a broad/in as broad fixed > - Section 3, third paragraph > server reflexive, NAT-assisted, tunneled, or relayed = candidates of these three types > Add reference to Section 5 for further explanation.=20 OK, fixed > - Section 3, Figure 1 > It would be helpful to either expand the figure to cover the = non-(D)TLS case as well or have another figure showing that for = comparison Do we really need one, considering the non-(D)TLS case is fairly = trivial, right? The "strangeness" in the (D)TLS case comes from the fact = that STUN is used outside of the (D)TLS connection.=20 Although, the figure caption should be updated to reflect the fact that = this is the (D)TLS case; now it says "ICE TCP Stack with (D)TLS". > - Section 4.2 > s/local-preference/local preference/ for consistency with RFC 5245 = (multiple occurrences) Good catch! Fixed. > - Section 4.2 > > The direction-pref MUST be between 0 and 7, with 7 being the most > preferred. The other-pref MUST be between 0 and 8191, with 8191 > being the most preferred.=20 > > Rephrase to make clear that 0 and 8191 (presumably) are both valid = values in these ranges.=20 OK, now it says:=20 The direction-pref MUST be between 0 and 7 (inclusive), with 7 being the most preferred. The other-pref MUST be between 0 and 8191 (inclusive), with 8191 being the most preferred. > - Section 4.3 > > If a media stream is inherently TCP-based, the agent MUST select an > active candidate as the default. This ensures proper = directionality > of connection establishment for NAT traversal with non-ICE > implementations. > > It doesn't ensure it, however under the assumption that the ICE = endpoint is behind a NAT, it enhances the likelihood of the connection = establishment succeeding.=20 I guess you're right. I'll have a closer look at this. > - Section 4.5 > > The connection-address and port encoded into the candidate = attribute > for active candidates MUST be set to the IP address that will be = used > for the attempt, but the port(s) MUST be set to 9 (i.e., Discard). > > - Delete the "and port" part.=20 Why? The "port" refers to the "port" and "rel-port" parts in the = candidate-attribute. > - Section 5, third paragraph > > If the local network or host > does not support IPv6 addressing, then clients SHOULD make use of > other techniques, e.g., Teredo [RFC4380] or SOCKS IPv4-IPv6 > gatewaying [RFC3089], for obtaining IPv6 candidates. > > Add "TURN-IPV6 [RFC6156]" to the beginning of the example list.=20 OK, fixed > - Section 5, 4th paragraph > > For > example, using multiple NAT-assisted techniques with the same NAT > usually results only in redundant candidates and similarly out of > multiple different UDP tunneling or relaying techniques with = similar > features using just one is often enough. > > Hard to read. Suggest breaking sentence in two ("...candidates. = Similarly, out of..."). Regardless, I'm not sure exaclty what "similar = features" implies here. An example would be good.=20 OK, I removed the "similar features" part (it was a bit redundant = anyway). Now it says: For example, using multiple NAT-assisted techniques with the same NAT usually results only in redundant candidates. Similarly, out of multiple different UDP tunneling or relaying techniques using just one is often enough. >=20 > - Section 5.3, last paragraph > Should reference the PCP WG and ongoing work there as well.=20 OK. I added PCP base to the beginning of the list of "other known = protocols". >=20 > - Section 5.5, last paragraph > > It is also possible to use, e.g., an SSH [RFC4250] tunnel=20 > > RFC 4251 would seem to be a better reference here.=20 Good point, fixed. > - Section 12 > s/sips/SIPS [RFC3261]/ fixed > - Section 15.2 > RFC 3261, 5389, 5766, and 6062 should all be normative rather = informative.=20 Fixed the first two, but 5776 (TURN) and 6062 (TURN TCP) are = intentionally informative since TURN is just one of the possible = techniques for relaying.=20 > - Appendix A > s/hand shake/handshake > s/SYNACK/SYN-AC fixed >=20 > - Please make sure to run id-nits check before submitting the update.=20= Will do. Although, at least all the current idnits complaints seem to be = false positives. Thanks, Ari > On 4/15/11 11:54 AM, Flemming Andreasen wrote: >> This is to announce a 2 week Working Group Last Call for=20 >>=20 >> draft-ietf-mmusic-ice-tcp-13 >>=20 >> as Proposed Standard. Please review and provide any comments you may = have on the document before Monday, May 2nd, 2011. Comments should be = sent to the document authors and the MMUSIC WG list.=20 >>=20 >>=20 >> Thanks=20 >>=20 >> Flemming & Miguel=20 >>=20 >>=20 >>=20 >> Draft Info: >>=20 >> =20 >> Title : TCP Candidates with Interactive Connectivity = Establishment (ICE) >> Author(s) : J. Rosenberg, et al. >> Filename : draft-ietf-mmusic-ice-tcp-13.txt >> Pages : 29 >> Date : 2011-04-11 >>=20 >> Interactive Connectivity Establishment (ICE) defines a mechanism for >> NAT traversal for multimedia communication protocols based on the >> offer/answer model of session negotiation. ICE works by providing a >> set of candidate transport addresses for each media stream, which are >> then validated with peer-to-peer connectivity checks based on Session >> Traversal Utilities for NAT (STUN). ICE provides a general framework >> for describing candidates, but only defines UDP-based transport >> protocols. This specification extends ICE to TCP-based media, >> including the ability to offer a mix of TCP and UDP-based candidates >> for a single stream. >>=20 >> A URL for this Internet-Draft is: >>=20 >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-13.txt >>=20 >> =20 >>=20 >>=20 From fandreas@cisco.com Thu May 12 14:05:19 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A19E07F9; Thu, 12 May 2011 14:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUAOIveRBU1z; Thu, 12 May 2011 14:05:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 10C4AE07F8; Thu, 12 May 2011 14:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=19242; q=dns/txt; s=iport; t=1305234318; x=1306443918; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=B7Se01zD8vtIJo/5BmmJpTWIcFCJ6ErFkeBdy98l8HU=; b=JVryAAllPgyoJ7WoyHtyHTJUIWCNXaex3YrJeqrNQ3f7SAzWyw2LaarL kp/MPT1KHbtWMXhcOVGPDUQhjlWLSb7hqx5aWvj7Lgb3X/iSh3qCtu0jd i+bkFYch5H55ATN7fR7tRag2WU3d+7sOlkAqIuHJhafhyZ/vwPu4eyGa7 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHdKzE2tJXG9/2dsb2JhbACCZKMVd4hwoXKeJ4YVBI97jwU X-IronPort-AV: E=Sophos;i="4.64,360,1301875200"; d="scan'208,217";a="314471743" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 12 May 2011 21:05:17 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4CL5Gek006222; Thu, 12 May 2011 21:05:16 GMT Message-ID: <4DCC4B8C.9040104@cisco.com> Date: Thu, 12 May 2011 17:05:16 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Ari Keranen References: <4DA86A44.9040909@cisco.com> <4DC89DB6.70008@cisco.com> <56FA6861-542E-422F-AEE2-5B987014E8A4@nomadiclab.com> In-Reply-To: <56FA6861-542E-422F-AEE2-5B987014E8A4@nomadiclab.com> Content-Type: multipart/alternative; boundary="------------000203050607070706090909" Cc: mmusic-chairs@ietf.org, mmusic , draft-ietf-mmusic-ice-tcp@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 21:05:20 -0000 This is a multi-part message in MIME format. --------------000203050607070706090909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/11/11 11:55 AM, Ari Keranen wrote: > > Hi Flemming, > > Thanks for the thorough review! See inline. > > On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote: > [...] > > - Section 7.1, third paragraph > > > > If the TCP connection cannot be established, the check is considered > > to have failed, and a full-mode agent MUST update the pair state to > > Failed in the check list. > > > > a) How long do you wait before determining it cannot be established > ? Need some considerations around this > > I have considered this as an implementation/platform detail: you do > connect() and wait until it succeeds or fails. Or do you have > suggestions what additional to recommend here? > Does RFC 5389 Section 7.2.2 simply apply directly here and hence we should just reference that ? > > b) Also, how fast do you attempt to establish additional TCP > connections ? Timer Ta considerations would seem to apply to the TCP > connection establishment here. > > Yes, the agents pace the start of the checks like for UDP. The end of > section 4.1 says "Like its UDP counterparts, TCP-based STUN > transactions are paced out at one every Ta seconds." It could be a bit > confusing that the comment is under "Gathering candidates" section, > but it refers to all STUN transactions. > I think we should mention it in Section 7.1, however looking at it again, I assume we simply following Section 5.8 from RFC 5245 (Scheduling Checks), and hence a reference to that effect would suffice. > > > - Section 11.1 > > The section seems to be written under the assumption that both sides > are full ICE Implementations. Need to consider lite implementations as > well. > > This seemed OK to me. What would you change here to accommodate also > lite agents? > You have the following text for example If the TCP connection is established, the framing of RFC 4571 is utilized. If the agent opened the connection, it MUST send a STUN connectivity check. That latter sentence would presumably only apply if the agent is a full implementation. Similarly If an agent receives a connectivity check after re- establishment of the connection, it MUST generate a triggered check over that connection in response if it has not already sent a check. Once an agent has sent a check and received a successful response, the connection is considered Valid and media can be sent (which includes a TLS or DTLS-SRTP session resumption or restart) seems to assume full ICE implementations. > > > - Section 12 > > I believe there is a TCP amplification attack similar to the STUN > amplification attack that requires consideration, since the TCP > connection is established prior to any STUN/ICE checks and involves > TCP state creation on the part of the attacked party. > > I guess you're right. We should document that, but any ideas for > mitigation? > I'm not sure - maybe we can limit the number of outstanding TCP connection attempts to the same IP-address ? It would probably be worthwhile asking some of the security experts here. > > > - Section 13 > > I was surprised to see no IANA considerations since "TCP" is defined > as a new transport-extension value here, however upon checking RFC > 5245, there apparently is no registry defined for this. RFC 5245 > Section 14 appears to indicate this was not an oversight at the time, > however with ice-tcp, I think we should define a registry. > > Good point; we'll add one in the next revision. > Ok. > > Editorial/Nits > > ========== > snipped the ones we're in sync on > > - Section 3, Figure 1 > > It would be helpful to either expand the figure to cover the > non-(D)TLS case as well or have another figure showing that for comparison > > Do we really need one, considering the non-(D)TLS case is fairly > trivial, right? The "strangeness" in the (D)TLS case comes from the > fact that STUN is used outside of the (D)TLS connection. > > Although, the figure caption should be updated to reflect the fact > that this is the (D)TLS case; now it says "ICE TCP Stack with (D)TLS". > You don't *need* it, but it would have been helpful to me the first time I read it at least. > > > - Section 4.2 > > > > The direction-pref MUST be between 0 and 7, with 7 being the most > > preferred. The other-pref MUST be between 0 and 8191, with 8191 > > being the most preferred. > > > > Rephrase to make clear that 0 and 8191 (presumably) are both valid > values in these ranges. > > OK, now it says: > > The direction-pref MUST be between 0 and 7 (inclusive), with 7 being > the most preferred. The other-pref MUST be between 0 and 8191 > (inclusive), with 8191 being the most preferred. > I'd say "both inclusive". > > > > - Section 4.5 > > > > The connection-address and port encoded into the candidate attribute > > for active candidates MUST be set to the IP address that will be used > > for the attempt, but the port(s) MUST be set to 9 (i.e., Discard). > > > > - Delete the "and port" part. > > Why? The "port" refers to the "port" and "rel-port" parts in the > candidate-attribute. > The sentence reads The connection-address and port encoded into the candidate attribute for active candidates MUST be set to the IP address that will be used for the attempt, You can only set the connection-address to the IP address, not the port. It's a nit. > > > - Section 15.2 > > RFC 3261, 5389, 5766, and 6062 should all be normative rather > informative. > > Fixed the first two, but 5776 (TURN) and 6062 (TURN TCP) are > intentionally informative since TURN is just one of the possible > techniques for relaying. > Except from http://www.rfc-editor.org/rfc-editor/instructions2authors.txt Within an RFC, references to other documents fall into two general categories: "normative" and "informative". Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it provides only additional information. For example, an informative reference might provide background or historical information. Material in an informative reference is not required to implement the technology in the RFC. In other words, just because you don't mandata the use of TURN doesn't automatically turn it into an informative reference (as I've been told I think the TURN text in e.g. Section 1, Section 4.1, Section 11.2 etc makes RFC 5766 a Normative reference per the above. RFC 6062 is perhaps more debatable. Thanks -- Flemming --------------000203050607070706090909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 5/11/11 11:55 AM, Ari Keranen wrote:
Re: WGLC for draft-ietf-mmusic-ice-tcp-13

Hi Flemming,

Thanks for the thorough review! See inline.

On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote:
[...]
> - Section 7.1, third paragraph
> <quote>
>    If the TCP connection cannot be established, the check is considered
>    to have failed, and a full-mode agent MUST update the pair state to
>    Failed in the check list.
> </quote>
> a) How long do you wait before determining it cannot be established ? Need some considerations around this

I have considered this as an implementation/platform detail: you do connect() and wait until it succeeds or fails. Or do you have suggestions what additional to recommend here?

Does RFC 5389 Section 7.2.2 simply apply directly here and hence we should just reference that ?


> b) Also, how fast do you attempt to establish additional TCP connections ? Timer Ta considerations would seem to apply to the TCP connection establishment here.

Yes, the agents pace the start of the checks like for UDP. The end of section 4.1 says "Like its UDP counterparts, TCP-based STUN transactions are paced out at one every Ta seconds." It could be a bit confusing that the comment is under "Gathering candidates" section, but it refers to all STUN transactions.

I think we should mention it in Section 7.1, however looking at it again, I assume we simply following Section 5.8 from RFC 5245 (Scheduling Checks), and hence a reference to that effect would suffice.


> - Section 11.1
> The section seems to be written under the assumption that both sides are full ICE Implementations. Need to consider lite implementations as well.

This seemed OK to me. What would you change here to accommodate also lite agents?


You have the following text for example
<quote>

If the TCP connection is established, the framing of RFC 4571 is

   utilized.  If the agent opened the connection, it MUST send a STUN

   connectivity check. 
</quote>

That latter sentence would presumably only apply if the agent is a full implementation.

Similarly
<quote>

If an agent receives a connectivity check after re-

   establishment of the connection, it MUST generate a triggered check

   over that connection in response if it has not already sent a check.

   Once an agent has sent a check and received a successful response,

   the connection is considered Valid and media can be sent (which

   includes a TLS or DTLS-SRTP session resumption or restart)
</quote>
seems to assume full ICE implementations.


> - Section 12
> I believe there is a TCP amplification attack similar to the STUN amplification attack that requires consideration, since the TCP connection is established prior to any STUN/ICE checks and involves TCP state creation on the part of the attacked party. 

I guess you're right. We should document that, but any ideas for mitigation?


I'm not sure - maybe we can limit the number of outstanding TCP connection attempts to the same IP-address ? It would probably be worthwhile asking some of the security experts here.


> - Section 13
> I was surprised to see no IANA considerations since "TCP" is defined as a new transport-extension value here, however upon checking RFC 5245, there apparently is no registry defined for this. RFC 5245 Section 14 appears to indicate this was not an oversight at the time, however with ice-tcp, I think we should define a registry. 

Good point; we'll add one in the next revision.

Ok.

> Editorial/Nits
> ==========

snipped the ones we're in sync on

> - Section 3, Figure 1
> It would be helpful to either expand the figure to cover the non-(D)TLS case as well or have another figure showing that for comparison

Do we really need one, considering the non-(D)TLS case is fairly trivial, right? The "strangeness" in the (D)TLS case comes from the fact that STUN is used outside of the (D)TLS connection.

Although, the figure caption should be updated to reflect the fact that this is the (D)TLS case; now it says "ICE TCP Stack with (D)TLS".

You don't *need* it, but it would have been helpful to me the first time I read it at least.



> - Section 4.2
> <quote>
> The direction-pref MUST be between 0 and 7, with 7 being the most
>    preferred.  The other-pref MUST be between 0 and 8191, with 8191
>    being the most preferred.
> </quote>
> Rephrase to make clear that 0 and 8191 (presumably) are both valid values in these ranges.

OK, now it says:

   The direction-pref MUST be between 0 and 7 (inclusive), with 7 being
   the most preferred.  The other-pref MUST be between 0 and 8191
   (inclusive), with 8191 being the most preferred.

I'd say "both inclusive".



> - Section 4.5
> <quote>
>    The connection-address and port encoded into the candidate attribute
>    for active candidates MUST be set to the IP address that will be used
>    for the attempt, but the port(s) MUST be set to 9 (i.e., Discard).
> </quote>
> - Delete the "and port" part.

Why? The "port" refers to the "port" and "rel-port" parts in the candidate-attribute.


The sentence reads
<quote>
   The connection-address and port encoded into the candidate attribute
   for active candidates MUST be set to the IP address that will be used
   for the attempt,
</quote>

You can only set the connection-address to the IP address, not the port. It's a nit.


> - Section 15.2
> RFC 3261, 5389, 5766, and 6062 should all be normative rather informative.

Fixed the first two, but 5776 (TURN) and 6062 (TURN TCP) are intentionally informative since TURN is just one of the possible techniques for relaying.

Except from http://www.rfc-editor.org/rfc-editor/instructions2authors.txt

<quote>
      Within an RFC, references to other documents fall into two general
      categories: "normative" and "informative".  Normative references
      specify documents that must be read to understand or implement the
      technology in the new RFC, or whose technology must be present for
      the technology in the new RFC to work.  An informative reference
      is not normative; rather, it provides only additional information.
      For example, an informative reference might provide background or
      historical information.  Material in an informative reference is
      not required to implement the technology in the RFC.
</quote>

In other words, just because you don't mandata the use of TURN doesn't automatically turn it into an informative reference (as I've been told

I think the TURN text in e.g. Section 1, Section 4.1, Section 11.2 etc makes RFC 5766 a Normative reference per the above. RFC 6062 is perhaps more debatable.

Thanks

-- Flemming


--------------000203050607070706090909-- From fandreas@cisco.com Thu May 12 17:05:45 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE182E079C for ; Thu, 12 May 2011 17:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOsls8ZiR67f for ; Thu, 12 May 2011 17:05:44 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFAFE079B for ; Thu, 12 May 2011 17:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=5848; q=dns/txt; s=iport; t=1305245144; x=1306454744; h=message-id:date:from:mime-version:to:cc:subject; bh=bK2O8uuoQX3zQzpHcN91BtbjhPdm4ZwJavvq/35w9KE=; b=Je9TA8CenFalnOKvpQf3t+lwHv61jEN2DiFDcm1txA9KBWx5m3rhpLVR G2GJmweoLta7XF/t/QzzIXLvhPlqTD5IQ72yIhP0SdYbA2Hk1npuh3pRo Rblfx2b1Gn++npRQsJ3UfY9XfQbki2J5/n6Mav4IXK5orNqndAio6iPrx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA91zE2tJV2c/2dsb2JhbACleXepbp4VhhUEj3yPBQ X-IronPort-AV: E=Sophos;i="4.64,361,1301875200"; d="scan'208,217";a="232852776" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 13 May 2011 00:05:43 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p4D05gS1004694; Fri, 13 May 2011 00:05:43 GMT Message-ID: <4DCC75D6.60203@cisco.com> Date: Thu, 12 May 2011 20:05:42 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: draft-ietf-mmusic-media-loopback@tools.ietf.org Content-Type: multipart/alternative; boundary="------------040706060105000902060209" Cc: mmusic Subject: [MMUSIC] Media loopback revisited (draft-ietf-mmusic-media-loopback-15.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 00:05:45 -0000 This is a multi-part message in MIME format. --------------040706060105000902060209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi I have taken a look at the updated media-loopback draft http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-15.txt and I consider it to be a subtantial improvement over v14. I still have two signficant comments, both of which probably require discussion with our ADs and/or the Payload WG chairs, however it would be useful for the MMUSIC WG participants to give their view on these as well: 1) Alternative NAT traversal mechanism (Section 5.7) One general question/comment for the group and our ADs, and two technical comments as well 1a) The draft defines an alternative NAT traversal mechanism instead of ICE, and this mechanism will only work in certain deployment scenarios under certain assumptions. The draft does say that ICE is the preferred mechanism and the alternative specified here should only be used if ICE is not available and you fulfill the deployment scenario requirements. Considering the intended status of the document is Proposed Standard, is this acceptable ? 1b) The draft allows for the answerer to add this NAT traversal mechanism as a media format to the answer, even if the offer did not include it. The draft furthermore requires the offerer to accept use of this mechanism then. This breaks normal O/A behavior and I don't see any good reason to do so. If the offerer supports and is willing to use this mechanism, he should include it in the offer. 1c) The draft seems to assume what is commonly referred to as latching behavior by the loopback-source inasmuch as in order for the mechanism to work, the loopback-source must send packets to the observed source IP-address and port rather than what was negotiated in the SDP. This operation however is not explained in the draft, and it needs to be (with a MUST). 2) Definition of several new RTP payload formats (Sections 7, 8, and 14.2) The draft defines several new RTP payload formats, however, as far as I know, the draft has not been reviewed in the PAYLOAD WG (or AVT prior to that). Ideally, there would be two different drafts, with the RTP payload part handled in PAYLOAD, and the other part handled in MMUSIC, however I'm sympathetic to the fact that we are on v15 of this draft. I have a few detailed comments as well that should be relatively easy to resolve, however I'll defer those until we figure out a path forward on the above. Thanks -- Flemming --------------040706060105000902060209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi

I have taken a look at the updated media-loopback draft
   
    http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-15.txt

and I consider it to be a subtantial improvement over v14. I still have two signficant comments, both of which probably require discussion with our ADs and/or the Payload WG chairs, however it would be useful for the MMUSIC WG participants to give their view on these as well:

1) Alternative NAT traversal mechanism (Section 5.7)
One general question/comment for the group and our ADs, and two technical comments as well
1a) The draft defines an alternative NAT traversal mechanism instead of ICE, and this mechanism will only work in certain deployment scenarios under certain assumptions. The draft does say that ICE is the preferred mechanism and the alternative specified here should only be used if ICE is not available and you fulfill the deployment scenario requirements.  Considering the intended status of the document is Proposed Standard, is this acceptable ?

1b) The draft allows for the answerer to add this NAT traversal mechanism as a media format to the answer, even if the offer did not include it. The draft furthermore requires the offerer to accept use of this mechanism then. This breaks normal O/A behavior and I don't see any good reason to do so. If the offerer supports and is willing to use this mechanism, he should include it in the offer.

1c) The draft seems to assume what is commonly referred to as latching behavior by the loopback-source inasmuch as in order for the mechanism to work, the loopback-source must send packets to the observed source IP-address and port rather than what was negotiated in the SDP. This operation however is not explained in the draft, and it needs to be (with a MUST).


2) Definition of several new RTP payload formats (Sections 7, 8, and 14.2)
The draft defines several new RTP payload formats, however, as far as I know, the draft has not been reviewed in the PAYLOAD WG (or AVT prior to that). Ideally, there would be two different drafts, with the RTP payload part handled in PAYLOAD, and the other part handled in MMUSIC, however I'm sympathetic to the fact that we are on v15 of this draft.


I have a few detailed comments as well that should be relatively easy to resolve, however I'll defer those until we figure out a path forward on the above.

Thanks

-- Flemming
--------------040706060105000902060209-- From Bert.Greevenbosch@huawei.com Thu May 12 17:49:01 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CABE06F1 for ; Thu, 12 May 2011 17:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OES8lxtCyOTP for ; Thu, 12 May 2011 17:49:01 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 07E94E065A for ; Thu, 12 May 2011 17:49:01 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL3004NJZLMCJ@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 13 May 2011 08:48:58 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL3004ZAZLMZV@szxga03-in.huawei.com> for mmusic@ietf.org; Fri, 13 May 2011 08:48:58 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 13 May 2011 08:48:53 +0800 Received: from SZXEML501-MBX.china.huawei.com ([169.254.5.158]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Fri, 13 May 2011 08:48:57 +0800 Date: Fri, 13 May 2011 00:48:56 +0000 From: Bert Greevenbosch In-reply-to: X-Originating-IP: [10.70.109.52] To: "Charles Eckel (eckelcu)" , "mmusic@ietf.org" Message-id: <46A1DF3F04371240B504290A071B4DB6012D237E@szxeml501-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] Question on unknown attributes in SDP offer/answer Thread-index: AcwOtmkZFU6Yd/DzREOAXyjmslhSwQAkKg8AAHAQ3oA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46A1DF3F04371240B504290A071B4DB6012C9739@SZXEML501-MBS.china.huawei.com> Subject: Re: [MMUSIC] Question on unknown attributes in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 00:49:02 -0000 Hi Charles, Thanks, that was what I was hoping for. I am preparing a new version of the draft that will reflect these issues. Best regards, Bert -----Original Message----- From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] Sent: 11 May 2011 03:30 To: Bert Greevenbosch; mmusic@ietf.org Subject: RE: [MMUSIC] Question on unknown attributes in SDP offer/answer Hi Bert, An end system that is producing an answer to an SDP offer that includes SDP attributes it does not understand should ignore those attributes and not include them within the answer. I find this to be done correctly by most implementations. Cheers, Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Bert Greevenbosch > Sent: Monday, May 09, 2011 7:03 PM > To: mmusic@ietf.org > Subject: [MMUSIC] Question on unknown attributes in SDP offer/answer > > Hi all, > > > > I have a question for the SDP offer/answer model experts. It is related to the "3dFormat" attribute > draft (http://tools.ietf.org/id/draft-greevenbosch-mmusic-signal-3d-format-00. txt). > > > > The issue has been touched before, but more in the context of frame packing. The current issue > concerns how a legacy device will treat the for it unknown "3dFormat" attribute, especially in SIP > negotiation. > > > > I have found the following related info: > > > > * The SDP spec (RFC 4566) defines that unknown attributes MUST be ignored: > "If an attribute is received that is not understood, it MUST be ignored by the receiver." (section > 5.13) > > * The SDP offer/answer spec (RFC 3264) gives no information about what to do with unknown > attributes. The spec does not say whether the answerer can/will omit unknown attributes in its answer. > > * The SIP spec (RFC 3261) specifies a warning code 306 "Attribute not understood: One or more > of the media attributes in the session description are not supported.". It does not mandate using this > warning code, or specify whether it can be used with a SIP 200 OK response. > > > > Ideal would be, when the answerer would omit SDP attributes it does not understand. In that case, the > offerer can detect the client does not understand the "3dFormat" attribute and can update its offer. > > > > Does any of you know more about how it works in praxis? Is there an established way on how current > implementations deal with unknown SDP attributes when doing SIP negotiation? > > > > Thanks a lot for your help! > > > > Best regards, > > Bert From internet-drafts@ietf.org Fri May 13 01:58:13 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA97E067B; Fri, 13 May 2011 01:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Amccx7vs4xIX; Fri, 13 May 2011 01:58:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83071E068B; Fri, 13 May 2011 01:58:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110513085813.16200.15546.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2011 01:58:13 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-options-registry-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 08:58:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : IANA Registry for Interactive Connectivity Establishment= (ICE) Options Author(s) : Magnus Westerlund Colin Perkins Filename : draft-ietf-mmusic-ice-options-registry-02.txt Pages : 5 Date : 2011-05-13 It has been identified that Interactive Connectivity Establishment (ICE) RFC5245 is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC5245. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-options-registry-= 02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-ice-options-registry-0= 2.txt From magnus.westerlund@ericsson.com Fri May 13 02:29:57 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A73E0695 for ; Fri, 13 May 2011 02:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.43 X-Spam-Level: X-Spam-Status: No, score=-106.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqXO3-iUbliL for ; Fri, 13 May 2011 02:29:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 79B0BE0707 for ; Fri, 13 May 2011 02:29:55 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-92-4dccf64bda6f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 77.D2.28525.B46FCCD4; Fri, 13 May 2011 11:13:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 13 May 2011 11:13:14 +0200 Message-ID: <4DCCF62A.6030801@ericsson.com> Date: Fri, 13 May 2011 11:13:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20110513085813.16200.15546.idtracker@ietfa.amsl.com> In-Reply-To: <20110513085813.16200.15546.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-options-registry-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 09:29:57 -0000 Hi, This is an update of the document to address the commentes received in IETF last call. Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-options-registry-02 Cheers Magnus On 2011-05-13 10:58, internet-drafts@ietf.org wrote: > 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 : IANA Registry for Interactive Connectivity Establishment (ICE) Options > Author(s) : Magnus Westerlund > Colin Perkins > Filename : draft-ietf-mmusic-ice-options-registry-02.txt > Pages : 5 > Date : 2011-05-13 > > It has been identified that Interactive Connectivity Establishment > (ICE) RFC5245 is missing a registry for ICE options. This document > defines this missing IANA registry and updates RFC5245. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-options-registry-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-ice-options-registry-02.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Bert.Greevenbosch@huawei.com Sun May 15 19:38:28 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D27E06D6 for ; Sun, 15 May 2011 19:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEfRIE2B3hyW for ; Sun, 15 May 2011 19:38:27 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 059D8E06B9 for ; Sun, 15 May 2011 19:38:27 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL900JR9ONT21@szxga04-in.huawei.com> for mmusic@ietf.org; Mon, 16 May 2011 10:38:17 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL9003EZONT5Z@szxga04-in.huawei.com> for mmusic@ietf.org; Mon, 16 May 2011 10:38:17 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 16 May 2011 10:38:16 +0800 Received: from SZXEML501-MBX.china.huawei.com ([169.254.5.158]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Mon, 16 May 2011 10:38:16 +0800 Date: Mon, 16 May 2011 02:38:15 +0000 From: Bert Greevenbosch In-reply-to: <4DCA6A67.10701@ericsson.com> X-Originating-IP: [10.70.109.52] To: "Miguel A. Garcia" , "Charles Eckel (eckelcu)" Message-id: <46A1DF3F04371240B504290A071B4DB6012D58AA@szxeml501-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] Question on unknown attributes in SDP offer/answer Thread-index: AcwOtmkZFU6Yd/DzREOAXyjmslhSwQAkKg8AAA/YnoAA+anJIA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46A1DF3F04371240B504290A071B4DB6012C9739@SZXEML501-MBS.china.huawei.com> <4DCA6A67.10701@ericsson.com> Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Question on unknown attributes in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 02:38:28 -0000 Hi Miguel, Thank you for pointing out this issue. I have reviewed your comment in more detail, especially by reading RFC 5853. Also from that RFC, I have understood that SBCs are not standardised, and can do many things, as long as end-to-end integrity protection is not enforced. As noted the RFC, it is very similar to a man-in-the-middle attack. SBCs, in general, can cause trouble with SIP negotiation. For example, they can remove attributes, change codec and remove path/routing information. If they remove unknown attributes, they might also remove the 3D signalling from the SDP. (Until they know the attribute of course.) The best thing would be for them not to remove unknown attributes. Some indeed will not do this, whereas others will. This is exactly the problem with their non-standardised nature, and it seems hard to cater for all of them. What do you think? Best regards, Bert -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: 11 May 2011 18:52 To: Charles Eckel (eckelcu) Cc: Bert Greevenbosch; mmusic@ietf.org Subject: Re: [MMUSIC] Question on unknown attributes in SDP offer/answer Hi Bert, I agree with Charles, if an attribute present in the SDP offer is not understood, it will be simply ignored, and then the SDP answer will be produced. Notice that the attribute not only needs to be understood by the recipient of the SDP offer, but also by possible intermediaries that inspect SDP, most notably SBCs. I guess most SBCs allow operators to decide on what to do with unknown attributes, in which case you have the possibility of the attribute to be filtered by an SBC. /Miguel On 10/05/2011 21:29, Charles Eckel (eckelcu) wrote: > Hi Bert, > > An end system that is producing an answer to an SDP offer that includes > SDP attributes it does not understand should ignore those attributes and > not include them within the answer. I find this to be done correctly by > most implementations. > > Cheers, > Charles > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Bert Greevenbosch >> Sent: Monday, May 09, 2011 7:03 PM >> To: mmusic@ietf.org >> Subject: [MMUSIC] Question on unknown attributes in SDP offer/answer >> >> Hi all, >> >> >> >> I have a question for the SDP offer/answer model experts. It is > related to the "3dFormat" attribute >> draft > (http://tools.ietf.org/id/draft-greevenbosch-mmusic-signal-3d-format-00. > txt). >> >> >> >> The issue has been touched before, but more in the context of frame > packing. The current issue >> concerns how a legacy device will treat the for it unknown "3dFormat" > attribute, especially in SIP >> negotiation. >> >> >> >> I have found the following related info: >> >> >> >> * The SDP spec (RFC 4566) defines that unknown attributes MUST > be ignored: >> "If an attribute is received that is not understood, it MUST be > ignored by the receiver." (section >> 5.13) >> >> * The SDP offer/answer spec (RFC 3264) gives no information > about what to do with unknown >> attributes. The spec does not say whether the answerer can/will omit > unknown attributes in its answer. >> >> * The SIP spec (RFC 3261) specifies a warning code 306 > "Attribute not understood: One or more >> of the media attributes in the session description are not > supported.". It does not mandate using this >> warning code, or specify whether it can be used with a SIP 200 OK > response. >> >> >> >> Ideal would be, when the answerer would omit SDP attributes it does > not understand. In that case, the >> offerer can detect the client does not understand the "3dFormat" > attribute and can update its offer. >> >> >> >> Does any of you know more about how it works in praxis? Is there an > established way on how current >> implementations deal with unknown SDP attributes when doing SIP > negotiation? >> >> >> >> Thanks a lot for your help! >> >> >> >> Best regards, >> >> Bert > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Sun May 15 23:59:54 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC925E0671 for ; Sun, 15 May 2011 23:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFBTW0NpGdCf for ; Sun, 15 May 2011 23:59:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8842AE069C for ; Sun, 15 May 2011 23:59:52 -0700 (PDT) X-AuditID: c1b4fb3d-b7c86ae000000b90-96-4dd0cb677e9e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A9.6C.02960.76BC0DD4; Mon, 16 May 2011 08:59:51 +0200 (CEST) Received: from [159.107.24.202] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 16 May 2011 08:59:50 +0200 Message-ID: <4DD0CB66.8000006@ericsson.com> Date: Mon, 16 May 2011 08:59:50 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bert Greevenbosch References: <46A1DF3F04371240B504290A071B4DB6012C9739@SZXEML501-MBS.china.huawei.com> <4DCA6A67.10701@ericsson.com> <46A1DF3F04371240B504290A071B4DB6012D58AA@szxeml501-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB6012D58AA@szxeml501-mbx.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Question on unknown attributes in SDP offer/answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 06:59:54 -0000 Hi Bert, Your assessment on SBCs is correct. Perhaps the only thing we can do is to make sure that if the extension is not understood by an endpoint or SBC, or if the SBC is filtering the extension for administrative reasons, at least the session can be established with a regular video stream, I mean, without the 3D. Notice that I am here assuming that you want to give priority to establishing the call without 3D over failing the call if 3D is not enabled. BR, Miguel On 16/05/2011 4:38, Bert Greevenbosch wrote: > Hi Miguel, > > Thank you for pointing out this issue. > > I have reviewed your comment in more detail, especially by reading RFC 5853. > > Also from that RFC, I have understood that SBCs are not standardised, and can do many things, as long as end-to-end integrity protection is not enforced. As noted the RFC, it is very similar to a man-in-the-middle attack. > > SBCs, in general, can cause trouble with SIP negotiation. For example, they can remove attributes, change codec and remove path/routing information. If they remove unknown attributes, they might also remove the 3D signalling from the SDP. (Until they know the attribute of course.) > > The best thing would be for them not to remove unknown attributes. Some indeed will not do this, whereas others will. This is exactly the problem with their non-standardised nature, and it seems hard to cater for all of them. > > What do you think? > > Best regards, > Bert > > > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: 11 May 2011 18:52 > To: Charles Eckel (eckelcu) > Cc: Bert Greevenbosch; mmusic@ietf.org > Subject: Re: [MMUSIC] Question on unknown attributes in SDP offer/answer > > Hi Bert, > > I agree with Charles, if an attribute present in the SDP offer is not > understood, it will be simply ignored, and then the SDP answer will be > produced. > > Notice that the attribute not only needs to be understood by the > recipient of the SDP offer, but also by possible intermediaries that > inspect SDP, most notably SBCs. I guess most SBCs allow operators to > decide on what to do with unknown attributes, in which case you have the > possibility of the attribute to be filtered by an SBC. > > /Miguel > > On 10/05/2011 21:29, Charles Eckel (eckelcu) wrote: >> Hi Bert, >> >> An end system that is producing an answer to an SDP offer that includes >> SDP attributes it does not understand should ignore those attributes and >> not include them within the answer. I find this to be done correctly by >> most implementations. >> >> Cheers, >> Charles >> >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Bert Greevenbosch >>> Sent: Monday, May 09, 2011 7:03 PM >>> To: mmusic@ietf.org >>> Subject: [MMUSIC] Question on unknown attributes in SDP offer/answer >>> >>> Hi all, >>> >>> >>> >>> I have a question for the SDP offer/answer model experts. It is >> related to the "3dFormat" attribute >>> draft >> (http://tools.ietf.org/id/draft-greevenbosch-mmusic-signal-3d-format-00. >> txt). >>> >>> >>> >>> The issue has been touched before, but more in the context of frame >> packing. The current issue >>> concerns how a legacy device will treat the for it unknown "3dFormat" >> attribute, especially in SIP >>> negotiation. >>> >>> >>> >>> I have found the following related info: >>> >>> >>> >>> * The SDP spec (RFC 4566) defines that unknown attributes MUST >> be ignored: >>> "If an attribute is received that is not understood, it MUST be >> ignored by the receiver." (section >>> 5.13) >>> >>> * The SDP offer/answer spec (RFC 3264) gives no information >> about what to do with unknown >>> attributes. The spec does not say whether the answerer can/will omit >> unknown attributes in its answer. >>> >>> * The SIP spec (RFC 3261) specifies a warning code 306 >> "Attribute not understood: One or more >>> of the media attributes in the session description are not >> supported.". It does not mandate using this >>> warning code, or specify whether it can be used with a SIP 200 OK >> response. >>> >>> >>> >>> Ideal would be, when the answerer would omit SDP attributes it does >> not understand. In that case, the >>> offerer can detect the client does not understand the "3dFormat" >> attribute and can update its offer. >>> >>> >>> >>> Does any of you know more about how it works in praxis? Is there an >> established way on how current >>> implementations deal with unknown SDP attributes when doing SIP >> negotiation? >>> >>> >>> >>> Thanks a lot for your help! >>> >>> >>> >>> Best regards, >>> >>> Bert >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From gorry@erg.abdn.ac.uk Tue May 17 13:48:41 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614F5E078A for ; Tue, 17 May 2011 13:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8fdf5wz1WBw for ; Tue, 17 May 2011 13:48:40 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAC8E0754 for ; Tue, 17 May 2011 13:48:33 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p4HKmAo8004351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 May 2011 21:48:11 +0100 (BST) Message-ID: <4DD2DF0B.9060309@erg.abdn.ac.uk> Date: Tue, 17 May 2011 21:48:11 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: mmusic@ietf.org References: <4D933186.2030804@erg.abdn.ac.uk> <4D94E5F6.90004@cisco.com> <4D94F905.4070307@cisco.com> <4DA4367C.9010104@ericsson.com> <4DA7B0F0.6050307@cisco.com> In-Reply-To: <4DA7B0F0.6050307@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: Flemming Andreasen Subject: [MMUSIC] Getting the SDP right for draft-ietf-dccp-udpencap-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 20:48:41 -0000 A new version of I-D, draft-ietf-dccp-udpencap-08.txt has been uplaoded, this includes new input and a rewrite of section 5, following the discussions in the Prague MMUSIC meeting and the mailing list. Comments/corrections are most welcome. We plan to revise this in a few weeks and submit the final version to the DCCP working group. best wishes, Gorry ---- Filename: draft-ietf-dccp-udpencap http://tools.ietf.org/id/draft-ietf-dccp-udpencap-08.txt Revision: 08 Title: Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) Creation date: 2011-05-17 WG ID: dccp Number of pages: 19 Abstract: This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the SDP information for DCCP defined in RFC 5762. From chimura730@oki.com Wed May 18 04:54:06 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B14E0670 for ; Wed, 18 May 2011 04:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nVpHZHzGjxO for ; Wed, 18 May 2011 04:54:05 -0700 (PDT) Received: from gwf1.oki.co.jp (gwf1.oki.co.jp [202.226.91.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1B932E0657 for ; Wed, 18 May 2011 04:54:04 -0700 (PDT) Received: by gwf1.oki.co.jp (Postfix, from userid 0) id 10A87CF996; Wed, 18 May 2011 20:54:07 +0900 (JST) Received: from s111h119.dm1.oii.oki.co.jp [172.26.101.119] by gwf1.oki.co.jp with ESMTP id WAA17200; Wed, 18 May 2011 20:54:07 +0900 Received: from s111h119.dm1.oii.oki.co.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8E33C398006; Wed, 18 May 2011 20:54:02 +0900 (JST) Received: from s24c46.dm1.oii.oki.co.jp (s24c46.dm1.oii.oki.co.jp [172.26.76.96]) by s111h119.dm1.oii.oki.co.jp (Postfix) with ESMTP id 831EB398002; Wed, 18 May 2011 20:54:02 +0900 (JST) Received: from PC17099 (t102l39.dm1.oii.oki.co.jp [10.55.78.39]) by s24c46.dm1.oii.oki.co.jp (Postfix) with ESMTP id 64E6F30F3F3; Wed, 18 May 2011 20:54:02 +0900 (JST) From: "Yasubumi CHIMURA" To: "'Miguel A. Garcia'" , "'DRAGE, Keith (Keith)'" References: <4DC791E0.7010908@ericsson.com> <4DC8D232.8000501@ericsson.com> Date: Wed, 18 May 2011 20:54:02 +0900 Message-ID: <646F70073B3B490EA5D77F7C2C70C15E@power.oki.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcwO1jYULQkyMtm1TdaFJId+hBcucAGeribA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 In-Reply-To: <4DC8D232.8000501@ericsson.com> Cc: 'Flemming Andreasen' , 'OKUMURA Shinji' , 'Yasubumi CHIMURA' , 'mmusic' Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 11:54:06 -0000 Hi Miguel, I'm Chimura from OKI-J and CIAJ. I have one comment about draft-salgueiro-mmusic-image-iana-registration. RFC4566 described the procedure following; RFC4566 p24 The media type registration SHOULD define the packet format for use with UDP transport. ... For media using other transport protocols, the field is protocol specific. Rules for interpretation of the sub- field MUST be defined when registering new protocols (see Section 8.2.2). Therefore, if it use without UDP transport in m=image, should be describe the packet format. And, if it use with UDP transport in m=image, should be describe the definition of fmt and the attribution(a=) of SDP. Best Regards, Yasu Chimura -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: Tuesday, May 10, 2011 2:51 PM To: DRAGE, Keith (Keith) Cc: mmusic; Flemming Andreasen; 'Yasubumi CHIMURA' Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration Hi Keith, An individual document will not go through an official WGLC, but I guess the working group can always get a closer look at it before the author submitting it as an individual submission. /Miguel On 09/05/2011 17:50, DRAGE, Keith (Keith) wrote: > If you are going to WGLC this document, surely you might as well make this a working group draft. > > If it is AD sponsored, then the first question is sufficient - look at it now, and then it goes for a four week IETF last call. > > Keith > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Miguel A. Garcia >> Sent: 09 May 2011 08:04 >> To: mmusic >> Cc: Flemming Andreasen; 'Yasubumi CHIMURA' >> Subject: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana- >> registration >> >> In relation with the registration of the SDP 'image' media type, we are >> going to try to expedite this draft, since it is a very simple missing >> registration. >> >> The idea is to progress the draft as an individual submission, >> AD-sponsored draft. So, the chairs would like the working group to take a >> closer look at it (it is a short one), so that we can go to WGLC in a >> short time frame. >> >> So please, send comments as soon as possible. Do not wait to the WGLC. >> >> BR, >> >> Miguel >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Thu May 19 00:30:25 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43ADCE0707 for ; Thu, 19 May 2011 00:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36oJtAKKfVHT for ; Thu, 19 May 2011 00:30:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABC6E0734 for ; Thu, 19 May 2011 00:30:23 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-b3-4dd4c70ebb48 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C9.55.09774.E07C4DD4; Thu, 19 May 2011 09:30:23 +0200 (CEST) Received: from [159.107.24.202] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 19 May 2011 09:30:22 +0200 Message-ID: <4DD4C70D.3050901@ericsson.com> Date: Thu, 19 May 2011 09:30:21 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Yasubumi CHIMURA References: <4DC791E0.7010908@ericsson.com> <4DC8D232.8000501@ericsson.com> <646F70073B3B490EA5D77F7C2C70C15E@power.oki.co.jp> In-Reply-To: <646F70073B3B490EA5D77F7C2C70C15E@power.oki.co.jp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: 'mmusic' , 'OKUMURA Shinji' , "'DRAGE, Keith \(Keith\)'" , 'Flemming Andreasen' Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 07:30:25 -0000 Hi Yasu, My opinions, as an individual, below. On 18/05/2011 13:54, Yasubumi CHIMURA wrote: > Hi Miguel, > > I'm Chimura from OKI-J and CIAJ. > > I have one comment about draft-salgueiro-mmusic-image-iana-registration. > > RFC4566 described the procedure following; > RFC4566 p24 > The media type registration SHOULD define the packet > format for use with UDP transport. > ... > For media using other transport protocols, the field is > protocol specific. Rules for interpretation of the sub- > field MUST be defined when registering new protocols (see Section > 8.2.2). > > Therefore, if it use without UDP transport in m=image, should be describe > the packet format. > > And, if it use with UDP transport in m=image, should be describe the > definition of fmt and the attribution(a=) of SDP. I get the point, I belive. But I doubt we can just define a single packet format for sending any type of "image" media types. I guess we should say that T38 is one of the possible packet formats, and the full packet format description when using UDP transport is described in ITU-T T.38 recommendation. If in the future, there are additional formats of "image" with UDP, then a different specification should describe the packet format. Also, notice that T38 allows several transport protocols, including TCP, UDP, UDPTL, RTP. My suggestion is that the registration of the media type "image" delegates the packet format description over UDP to the media format description. Also, the draft should say that, when T38 is the media format, ITU-T T.38 contains the packet format description. BR, Miguel > > Best Regards, > > Yasu Chimura > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Tuesday, May 10, 2011 2:51 PM > To: DRAGE, Keith (Keith) > Cc: mmusic; Flemming Andreasen; 'Yasubumi CHIMURA' > Subject: Re: [MMUSIC] Process for > draft-salgueiro-mmusic-image-iana-registration > > Hi Keith, > > An individual document will not go through an official WGLC, but I guess > the working group can always get a closer look at it before the author > submitting it as an individual submission. > > /Miguel > > On 09/05/2011 17:50, DRAGE, Keith (Keith) wrote: >> If you are going to WGLC this document, surely you might as well make this > a working group draft. >> >> If it is AD sponsored, then the first question is sufficient - look at it > now, and then it goes for a four week IETF last call. >> >> Keith >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >>> Of Miguel A. Garcia >>> Sent: 09 May 2011 08:04 >>> To: mmusic >>> Cc: Flemming Andreasen; 'Yasubumi CHIMURA' >>> Subject: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana- >>> registration >>> >>> In relation with the registration of the SDP 'image' media type, we are >>> going to try to expedite this draft, since it is a very simple missing >>> registration. >>> >>> The idea is to progress the draft as an individual submission, >>> AD-sponsored draft. So, the chairs would like the working group to take a >>> closer look at it (it is a short one), so that we can go to WGLC in a >>> short time frame. >>> >>> So please, send comments as soon as possible. Do not wait to the WGLC. >>> >>> BR, >>> >>> Miguel >>> -- >>> Miguel A. Garcia >>> +34-91-339-3608 >>> Ericsson Spain >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ari.keranen@nomadiclab.com Thu May 19 07:29:37 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C38E06C9 for ; Thu, 19 May 2011 07:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFKbi205VKSL for ; Thu, 19 May 2011 07:29:37 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id B83D1E067B for ; Thu, 19 May 2011 07:29:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 5806E4E6D8 for ; Thu, 19 May 2011 17:29:27 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iISstq8ccGTy for ; Thu, 19 May 2011 17:29:26 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 4717A4E6BD for ; Thu, 19 May 2011 17:29:26 +0300 (EEST) From: Ari Keranen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 May 2011 17:29:26 +0300 Message-Id: To: mmusic WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [MMUSIC] ICE TCP and TCP amplification attack (mitigation) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 14:29:37 -0000 Hi all, Flemming identified a possible TCP amplification attack in ICE TCP: On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote: > - Section 12 > I believe there is a TCP amplification attack similar to the STUN = amplification attack that requires consideration, since the TCP = connection is established prior to any STUN/ICE checks and involves TCP = state creation on the part of the attacked party. That is, an attacker could put in the SDP offer a set of passive = reflexive candidates with the address of the victim and the answerer = would make a bunch of TCP connections towards the victim. A possible mitigation, as Flemming suggested, would be to limit the = number of outstanding TCP connection attempts to the same IP-address. = That sounds reasonable to me, since having many (un-frozen) candidates = from the same IP address seem unlikely anyway, but are there any other = ideas? Cheers, Ari= From ari.keranen@nomadiclab.com Thu May 19 07:40:21 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A243AE0743; Thu, 19 May 2011 07:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6+YPpHeO+xz; Thu, 19 May 2011 07:40:20 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 15E41E071A; Thu, 19 May 2011 07:40:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 93D134E6D8; Thu, 19 May 2011 17:40:18 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mGQIXOcEXjF; Thu, 19 May 2011 17:40:17 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id EB97B4E6BD; Thu, 19 May 2011 17:40:16 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: <4DCC4B8C.9040104@cisco.com> Date: Thu, 19 May 2011 17:40:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <030CB46E-A5FD-49C1-A7F4-B3329CD04EB5@nomadiclab.com> References: <4DA86A44.9040909@cisco.com> <4DC89DB6.70008@cisco.com> <56FA6861-542E-422F-AEE2-5B987014E8A4@nomadiclab.com> <4DCC4B8C.9040104@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.1084) Cc: "mmusic-chairs@ietf.org" , mmusic , "draft-ietf-mmusic-ice-tcp@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 14:40:21 -0000 On May 13, 2011, at 12:05 AM, Flemming Andreasen wrote: > On 5/11/11 11:55 AM, Ari Keranen wrote: >> Hi Flemming, >>=20 >> Thanks for the thorough review! See inline. >>=20 >> On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote: >> [...] >> > - Section 7.1, third paragraph >> > >> > If the TCP connection cannot be established, the check is = considered >> > to have failed, and a full-mode agent MUST update the pair state = to >> > Failed in the check list. >> > >> > a) How long do you wait before determining it cannot be established = ? Need some considerations around this >>=20 >> I have considered this as an implementation/platform detail: you do = connect() and wait until it succeeds or fails. Or do you have = suggestions what additional to recommend here? >>=20 >>=20 > Does RFC 5389 Section 7.2.2 simply apply directly here and hence we = should just reference that ?=20 That's probably the easiest fix. I'll add a reference to that =10(after = the sentence you quoted): "See Section 7.2.2 in [RFC5389] for more = details on STUN over TCP". >=20 >> > b) Also, how fast do you attempt to establish additional TCP = connections ? Timer Ta considerations would seem to apply to the TCP = connection establishment here. >>=20 >> Yes, the agents pace the start of the checks like for UDP. The end of = section 4.1 says "Like its UDP counterparts, TCP-based STUN transactions = are paced out at one every Ta seconds." It could be a bit confusing that = the comment is under "Gathering candidates" section, but it refers to = all STUN transactions. >>=20 > I think we should mention it in Section 7.1, however looking at it = again, I assume we simply following Section 5.8 from RFC 5245 = (Scheduling Checks), and hence a reference to that effect would suffice.=20= OK; that's actually true for the whole document (5245 procedures are = followed unless said otherwise), but I guess it makes sense to make this = more explicit here too. Right before 7.1 it says now (added the = reference part between commas): [...] The TCP candidate pairs are in the same checklist with the UDP candidate pairs and they are scheduled for connectivity checks, as described in Section 5.8 in [RFC5245], based on the priority order. >>=20 >> > - Section 11.1 >> > The section seems to be written under the assumption that both = sides are full ICE Implementations. Need to consider lite = implementations as well. >>=20 >> This seemed OK to me. What would you change here to accommodate also = lite agents? >>=20 >=20 > You have the following text for example > > If the TCP connection is established, the framing of RFC 4571 is > utilized. If the agent opened the connection, it MUST send a STUN > connectivity check. =20 > =20 >=20 > That latter sentence would presumably only apply if the agent is a = full implementation.=20 True, but a lite agent would not open (initiate) a connection if it has = only passive candidates. The default candidate complicates this a bit = though; I added "and is a full agent" clarification there to make it = more clear. > Similarly > > If an agent receives a connectivity check after re- > establishment of the connection, it MUST generate a triggered check > over that connection in response if it has not already sent a = check. > Once an agent has sent a check and received a successful response,=20= > the connection is considered Valid and media can be sent (which > includes a TLS or DTLS-SRTP session resumption or restart)=20 > > seems to assume full ICE implementations.=20 True. I changed that into "If a full agent [...]". >>=20 >> > - Section 12 >> > I believe there is a TCP amplification attack similar to the STUN = amplification attack that requires consideration, since the TCP = connection is established prior to any STUN/ICE checks and involves TCP = state creation on the part of the attacked party.=20 >>=20 >> I guess you're right. We should document that, but any ideas for = mitigation? >>=20 >=20 > I'm not sure - maybe we can limit the number of outstanding TCP = connection attempts to the same IP-address ? It would probably be = worthwhile asking some of the security experts here. That should work. Anyway, I sent a separate mail about this to the list. [..] >=20 >> > - Section 3, Figure 1 >> > It would be helpful to either expand the figure to cover the = non-(D)TLS case as well or have another figure showing that for = comparison >>=20 >> Do we really need one, considering the non-(D)TLS case is fairly = trivial, right? The "strangeness" in the (D)TLS case comes from the fact = that STUN is used outside of the (D)TLS connection. >>=20 >> Although, the figure caption should be updated to reflect the fact = that this is the (D)TLS case; now it says "ICE TCP Stack with (D)TLS". >>=20 >>=20 > You don't *need* it, but it would have been helpful to me the first = time I read it at least.=20 OK, I'll see how combining those two in the same figure works out. >=20 >>=20 >> > - Section 4.2 >> > >> > The direction-pref MUST be between 0 and 7, with 7 being the most >> > preferred. The other-pref MUST be between 0 and 8191, with 8191 >> > being the most preferred. >> > >> > Rephrase to make clear that 0 and 8191 (presumably) are both valid = values in these ranges. >>=20 >> OK, now it says: >>=20 >> The direction-pref MUST be between 0 and 7 (inclusive), with 7 = being >> the most preferred. The other-pref MUST be between 0 and 8191 >> (inclusive), with 8191 being the most preferred. >>=20 >>=20 > I'd say "both inclusive".=20 Fixed. >=20 >>=20 >>=20 >> > - Section 4.5 >> > >> > The connection-address and port encoded into the candidate = attribute >> > for active candidates MUST be set to the IP address that will be = used >> > for the attempt, but the port(s) MUST be set to 9 (i.e., = Discard). >> > >> > - Delete the "and port" part. >>=20 >> Why? The "port" refers to the "port" and "rel-port" parts in the = candidate-attribute. >>=20 >>=20 >=20 > The sentence reads > > The connection-address and port encoded into the candidate = attribute > for active candidates MUST be set to the IP address that will be = used > for the attempt, > >=20 > You can only set the connection-address to the IP address, not the = port. It's a nit.=20 Ah, yes, good catch. Actually, it should say "[...] MUST be set to the = IP address and port" (fixed). >>=20 >> > - Section 15.2 >> > RFC 3261, 5389, 5766, and 6062 should all be normative rather = informative. >>=20 >> Fixed the first two, but 5776 (TURN) and 6062 (TURN TCP) are = intentionally informative since TURN is just one of the possible = techniques for relaying. >>=20 >>=20 > Except from = http://www.rfc-editor.org/rfc-editor/instructions2authors.txt >=20 > > Within an RFC, references to other documents fall into two = general > categories: "normative" and "informative". Normative references > specify documents that must be read to understand or implement = the > technology in the new RFC, or whose technology must be present = for > the technology in the new RFC to work. An informative reference > is not normative; rather, it provides only additional = information. > For example, an informative reference might provide background = or > historical information. Material in an informative reference is > not required to implement the technology in the RFC. > >=20 > In other words, just because you don't mandata the use of TURN doesn't = automatically turn it into an informative reference (as I've been told=20= >=20 > I think the TURN text in e.g. Section 1, Section 4.1, Section 11.2 etc = makes RFC 5766 a Normative reference per the above. RFC 6062 is perhaps = more debatable.=20 OK. The idea was to have TURN "at the same level" as the other = techniques and that's why it is informative, like the rest. That said, = it's true that TURN has a bit of special attention in the text and I'm = OK with moving 5766 to normative. Cheers, Ari From fandreas@cisco.com Thu May 19 14:09:19 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8D0E0719; Thu, 19 May 2011 14:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gn5GGmv4s-Is; Thu, 19 May 2011 14:09:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0171BE06AE; Thu, 19 May 2011 14:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=20405; q=dns/txt; s=iport; t=1305839357; x=1307048957; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Nknj2RvZmreOp8CVDutxIuywssr4hxJdEa8t3vPwmkg=; b=dhC+fdGiibqYRtzPqyLWTCS0ZlO6skho1jKkOn41CDNo77LfbgSef3nA 5IsvAcx0AYXqWpZl3ed0ghRuadSZRmmESUWkouwRXQHCWyLFz78aDeguM NIaHmfzFT7dO5f/Fyghwmj96eKwKWHjRZC3BZMqOGaANpsGV6gZ1AhxWw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMaG1U2tJV2Z/2dsb2JhbACmFHeIcKAdnhKGGQSQEY8R X-IronPort-AV: E=Sophos;i="4.65,239,1304294400"; d="scan'208,217";a="451060735" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 19 May 2011 21:09:12 +0000 Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4JL9BJp018170; Thu, 19 May 2011 21:09:11 GMT Message-ID: <4DD586F7.3080407@cisco.com> Date: Thu, 19 May 2011 17:09:11 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Ari Keranen References: <4DA86A44.9040909@cisco.com> <4DC89DB6.70008@cisco.com> <56FA6861-542E-422F-AEE2-5B987014E8A4@nomadiclab.com> <4DCC4B8C.9040104@cisco.com> <030CB46E-A5FD-49C1-A7F4-B3329CD04EB5@nomadiclab.com> In-Reply-To: <030CB46E-A5FD-49C1-A7F4-B3329CD04EB5@nomadiclab.com> Content-Type: multipart/alternative; boundary="------------090304020902010501020308" Cc: mmusic-chairs@ietf.org, mmusic , draft-ietf-mmusic-ice-tcp@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 21:09:19 -0000 This is a multi-part message in MIME format. --------------090304020902010501020308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks Ari This addresses all of my comments (modulo any additional suggestions for better ways of mitigating the TCP amplification attack). -- Flemming On 5/19/11 10:40 AM, Ari Keranen wrote: > > On May 13, 2011, at 12:05 AM, Flemming Andreasen wrote: > > On 5/11/11 11:55 AM, Ari Keranen wrote: > >> Hi Flemming, > >> > >> Thanks for the thorough review! See inline. > >> > >> On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote: > >> [...] > >> > - Section 7.1, third paragraph > >> > > >> > If the TCP connection cannot be established, the check is > considered > >> > to have failed, and a full-mode agent MUST update the pair > state to > >> > Failed in the check list. > >> > > >> > a) How long do you wait before determining it cannot be > established ? Need some considerations around this > >> > >> I have considered this as an implementation/platform detail: you do > connect() and wait until it succeeds or fails. Or do you have > suggestions what additional to recommend here? > >> > >> > > Does RFC 5389 Section 7.2.2 simply apply directly here and hence we > should just reference that ? > > That's probably the easiest fix. I'll add a reference to that (after > the sentence you quoted): "See Section 7.2.2 in [RFC5389] for more > details on STUN over TCP". > > > > >> > b) Also, how fast do you attempt to establish additional TCP > connections ? Timer Ta considerations would seem to apply to the TCP > connection establishment here. > >> > >> Yes, the agents pace the start of the checks like for UDP. The end > of section 4.1 says "Like its UDP counterparts, TCP-based STUN > transactions are paced out at one every Ta seconds." It could be a bit > confusing that the comment is under "Gathering candidates" section, > but it refers to all STUN transactions. > >> > > I think we should mention it in Section 7.1, however looking at it > again, I assume we simply following Section 5.8 from RFC 5245 > (Scheduling Checks), and hence a reference to that effect would suffice. > > OK; that's actually true for the whole document (5245 procedures are > followed unless said otherwise), but I guess it makes sense to make > this more explicit here too. Right before 7.1 it says now (added the > reference part between commas): > > [...] The TCP candidate pairs are in the same > checklist with the UDP candidate pairs and they are scheduled for > connectivity checks, as described in Section 5.8 in [RFC5245], based > on the priority order. > > >> > >> > - Section 11.1 > >> > The section seems to be written under the assumption that both > sides are full ICE Implementations. Need to consider lite > implementations as well. > >> > >> This seemed OK to me. What would you change here to accommodate > also lite agents? > >> > > > > You have the following text for example > > > > If the TCP connection is established, the framing of RFC 4571 is > > utilized. If the agent opened the connection, it MUST send a STUN > > connectivity check. > > > > > > That latter sentence would presumably only apply if the agent is a > full implementation. > > True, but a lite agent would not open (initiate) a connection if it > has only passive candidates. The default candidate complicates this a > bit though; I added "and is a full agent" clarification there to make > it more clear. > > > Similarly > > > > If an agent receives a connectivity check after re- > > establishment of the connection, it MUST generate a triggered check > > over that connection in response if it has not already sent a check. > > Once an agent has sent a check and received a successful response, > > the connection is considered Valid and media can be sent (which > > includes a TLS or DTLS-SRTP session resumption or restart) > > > > seems to assume full ICE implementations. > > True. I changed that into "If a full agent [...]". > > >> > >> > - Section 12 > >> > I believe there is a TCP amplification attack similar to the STUN > amplification attack that requires consideration, since the TCP > connection is established prior to any STUN/ICE checks and involves > TCP state creation on the part of the attacked party. > >> > >> I guess you're right. We should document that, but any ideas for > mitigation? > >> > > > > I'm not sure - maybe we can limit the number of outstanding TCP > connection attempts to the same IP-address ? It would probably be > worthwhile asking some of the security experts here. > > That should work. Anyway, I sent a separate mail about this to the list. > > [..] > > > >> > - Section 3, Figure 1 > >> > It would be helpful to either expand the figure to cover the > non-(D)TLS case as well or have another figure showing that for comparison > >> > >> Do we really need one, considering the non-(D)TLS case is fairly > trivial, right? The "strangeness" in the (D)TLS case comes from the > fact that STUN is used outside of the (D)TLS connection. > >> > >> Although, the figure caption should be updated to reflect the fact > that this is the (D)TLS case; now it says "ICE TCP Stack with (D)TLS". > >> > >> > > You don't *need* it, but it would have been helpful to me the first > time I read it at least. > > OK, I'll see how combining those two in the same figure works out. > > > > >> > >> > - Section 4.2 > >> > > >> > The direction-pref MUST be between 0 and 7, with 7 being the most > >> > preferred. The other-pref MUST be between 0 and 8191, with 8191 > >> > being the most preferred. > >> > > >> > Rephrase to make clear that 0 and 8191 (presumably) are both > valid values in these ranges. > >> > >> OK, now it says: > >> > >> The direction-pref MUST be between 0 and 7 (inclusive), with 7 being > >> the most preferred. The other-pref MUST be between 0 and 8191 > >> (inclusive), with 8191 being the most preferred. > >> > >> > > I'd say "both inclusive". > > Fixed. > > > > >> > >> > >> > - Section 4.5 > >> > > >> > The connection-address and port encoded into the candidate > attribute > >> > for active candidates MUST be set to the IP address that will > be used > >> > for the attempt, but the port(s) MUST be set to 9 (i.e., Discard). > >> > > >> > - Delete the "and port" part. > >> > >> Why? The "port" refers to the "port" and "rel-port" parts in the > candidate-attribute. > >> > >> > > > > The sentence reads > > > > The connection-address and port encoded into the candidate attribute > > for active candidates MUST be set to the IP address that will be used > > for the attempt, > > > > > > You can only set the connection-address to the IP address, not the > port. It's a nit. > > Ah, yes, good catch. Actually, it should say "[...] MUST be set to the > IP address and port" (fixed). > > > >> > >> > - Section 15.2 > >> > RFC 3261, 5389, 5766, and 6062 should all be normative rather > informative. > >> > >> Fixed the first two, but 5776 (TURN) and 6062 (TURN TCP) are > intentionally informative since TURN is just one of the possible > techniques for relaying. > >> > >> > > Except from > http://www.rfc-editor.org/rfc-editor/instructions2authors.txt > > > > > > Within an RFC, references to other documents fall into two general > > categories: "normative" and "informative". Normative references > > specify documents that must be read to understand or implement the > > technology in the new RFC, or whose technology must be present for > > the technology in the new RFC to work. An informative reference > > is not normative; rather, it provides only additional information. > > For example, an informative reference might provide background or > > historical information. Material in an informative reference is > > not required to implement the technology in the RFC. > > > > > > In other words, just because you don't mandata the use of TURN > doesn't automatically turn it into an informative reference (as I've > been told > > > > I think the TURN text in e.g. Section 1, Section 4.1, Section 11.2 > etc makes RFC 5766 a Normative reference per the above. RFC 6062 is > perhaps more debatable. > > OK. The idea was to have TURN "at the same level" as the other > techniques and that's why it is informative, like the rest. That said, > it's true that TURN has a bit of special attention in the text and I'm > OK with moving 5766 to normative. > > > Cheers, > Ari > --------------090304020902010501020308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Ari

This addresses all of my comments (modulo any additional suggestions for better ways of mitigating the TCP amplification attack).

-- Flemming


On 5/19/11 10:40 AM, Ari Keranen wrote:
Re: WGLC for draft-ietf-mmusic-ice-tcp-13

On May 13, 2011, at 12:05 AM, Flemming Andreasen wrote:
> On 5/11/11 11:55 AM, Ari Keranen wrote:
>> Hi Flemming,
>>
>> Thanks for the thorough review! See inline.
>>
>> On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote:
>> [...]
>> > - Section 7.1, third paragraph
>> > <quote>
>> >    If the TCP connection cannot be established, the check is considered
>> >    to have failed, and a full-mode agent MUST update the pair state to
>> >    Failed in the check list.
>> > </quote>
>> > a) How long do you wait before determining it cannot be established ? Need some considerations around this
>>
>> I have considered this as an implementation/platform detail: you do connect() and wait until it succeeds or fails. Or do you have suggestions what additional to recommend here?
>>
>>
> Does RFC 5389 Section 7.2.2 simply apply directly here and hence we should just reference that ?

That's probably the easiest fix. I'll add a reference to that (after the sentence you quoted): "See Section 7.2.2 in [RFC5389] for more details on STUN over TCP".

>
>> > b) Also, how fast do you attempt to establish additional TCP connections ? Timer Ta considerations would seem to apply to the TCP connection establishment here.
>>
>> Yes, the agents pace the start of the checks like for UDP. The end of section 4.1 says "Like its UDP counterparts, TCP-based STUN transactions are paced out at one every Ta seconds." It could be a bit confusing that the comment is under "Gathering candidates" section, but it refers to all STUN transactions.
>>
> I think we should mention it in Section 7.1, however looking at it again, I assume we simply following Section 5.8 from RFC 5245 (Scheduling Checks), and hence a reference to that effect would suffice.

OK; that's actually true for the whole document (5245 procedures are followed unless said otherwise), but I guess it makes sense to make this more explicit here too. Right before 7.1 it says now (added the reference part between commas):

   [...] The TCP candidate pairs are in the same
   checklist with the UDP candidate pairs and they are scheduled for
   connectivity checks, as described in Section 5.8 in [RFC5245], based
   on the priority order.

>>
>> > - Section 11.1
>> > The section seems to be written under the assumption that both sides are full ICE Implementations. Need to consider lite implementations as well.
>>
>> This seemed OK to me. What would you change here to accommodate also lite agents?
>>
>
> You have the following text for example
> <quote>
> If the TCP connection is established, the framing of RFC 4571 is
>    utilized.  If the agent opened the connection, it MUST send a STUN
>    connectivity check. 
> </quote>
>
> That latter sentence would presumably only apply if the agent is a full implementation.

True, but a lite agent would not open (initiate) a connection if it has only passive candidates. The default candidate complicates this a bit though; I added "and is a full agent" clarification there to make it more clear.

> Similarly
> <quote>
> If an agent receives a connectivity check after re-
>    establishment of the connection, it MUST generate a triggered check
>    over that connection in response if it has not already sent a check.
>    Once an agent has sent a check and received a successful response,
>    the connection is considered Valid and media can be sent (which
>    includes a TLS or DTLS-SRTP session resumption or restart)
> </quote>
> seems to assume full ICE implementations.

True. I changed that into "If a full agent [...]".

>>
>> > - Section 12
>> > I believe there is a TCP amplification attack similar to the STUN amplification attack that requires consideration, since the TCP connection is established prior to any STUN/ICE checks and involves TCP state creation on the part of the attacked party.
>>
>> I guess you're right. We should document that, but any ideas for mitigation?
>>
>
> I'm not sure - maybe we can limit the number of outstanding TCP connection attempts to the same IP-address ? It would probably be worthwhile asking some of the security experts here.

That should work. Anyway, I sent a separate mail about this to the list.

[..]
>
>> > - Section 3, Figure 1
>> > It would be helpful to either expand the figure to cover the non-(D)TLS case as well or have another figure showing that for comparison
>>
>> Do we really need one, considering the non-(D)TLS case is fairly trivial, right? The "strangeness" in the (D)TLS case comes from the fact that STUN is used outside of the (D)TLS connection.
>>
>> Although, the figure caption should be updated to reflect the fact that this is the (D)TLS case; now it says "ICE TCP Stack with (D)TLS".
>>
>>
> You don't *need* it, but it would have been helpful to me the first time I read it at least.

OK, I'll see how combining those two in the same figure works out.

>
>>
>> > - Section 4.2
>> > <quote>
>> > The direction-pref MUST be between 0 and 7, with 7 being the most
>> >    preferred.  The other-pref MUST be between 0 and 8191, with 8191
>> >    being the most preferred.
>> > </quote>
>> > Rephrase to make clear that 0 and 8191 (presumably) are both valid values in these ranges.
>>
>> OK, now it says:
>>
>>    The direction-pref MUST be between 0 and 7 (inclusive), with 7 being
>>    the most preferred.  The other-pref MUST be between 0 and 8191
>>    (inclusive), with 8191 being the most preferred.
>>
>>
> I'd say "both inclusive".

Fixed.

>
>>
>>
>> > - Section 4.5
>> > <quote>
>> >    The connection-address and port encoded into the candidate attribute
>> >    for active candidates MUST be set to the IP address that will be used
>> >    for the attempt, but the port(s) MUST be set to 9 (i.e., Discard).
>> > </quote>
>> > - Delete the "and port" part.
>>
>> Why? The "port" refers to the "port" and "rel-port" parts in the candidate-attribute.
>>
>>
>
> The sentence reads
> <quote>
>    The connection-address and port encoded into the candidate attribute
>    for active candidates MUST be set to the IP address that will be used
>    for the attempt,
> </quote>
>
> You can only set the connection-address to the IP address, not the port. It's a nit.

Ah, yes, good catch. Actually, it should say "[...] MUST be set to the IP address and port" (fixed).


>>
>> > - Section 15.2
>> > RFC 3261, 5389, 5766, and 6062 should all be normative rather informative.
>>
>> Fixed the first two, but 5776 (TURN) and 6062 (TURN TCP) are intentionally informative since TURN is just one of the possible techniques for relaying.
>>
>>
> Except from http://www.rfc-editor.org/rfc-editor/instructions2authors.txt
>
> <quote>
>       Within an RFC, references to other documents fall into two general
>       categories: "normative" and "informative".  Normative references
>       specify documents that must be read to understand or implement the
>       technology in the new RFC, or whose technology must be present for
>       the technology in the new RFC to work.  An informative reference
>       is not normative; rather, it provides only additional information.
>       For example, an informative reference might provide background or
>       historical information.  Material in an informative reference is
>       not required to implement the technology in the RFC.
> </quote>
>
> In other words, just because you don't mandata the use of TURN doesn't automatically turn it into an informative reference (as I've been told
>
> I think the TURN text in e.g. Section 1, Section 4.1, Section 11.2 etc makes RFC 5766 a Normative reference per the above. RFC 6062 is perhaps more debatable.

OK. The idea was to have TURN "at the same level" as the other techniques and that's why it is informative, like the rest. That said, it's true that TURN has a bit of special attention in the text and I'm OK with moving 5766 to normative.


Cheers,
Ari

--------------090304020902010501020308-- From chimura730@oki.com Thu May 19 21:51:03 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C75DE06D7 for ; Thu, 19 May 2011 21:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpNWiPYxXTJo for ; Thu, 19 May 2011 21:51:02 -0700 (PDT) Received: from gwf1.oki.co.jp (gwf1.oki.co.jp [202.226.91.186]) by ietfa.amsl.com (Postfix) with ESMTP id 64F41E06C7 for ; Thu, 19 May 2011 21:51:02 -0700 (PDT) Received: by gwf1.oki.co.jp (Postfix, from userid 0) id 549BFCFABA; Fri, 20 May 2011 13:51:03 +0900 (JST) Received: from s111h119.dm1.oii.oki.co.jp [172.26.101.119] by gwf1.oki.co.jp with ESMTP id PAA18816; Fri, 20 May 2011 13:51:03 +0900 Received: from s111h119.dm1.oii.oki.co.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8E168398003; Fri, 20 May 2011 13:51:00 +0900 (JST) Received: from s24c46.dm1.oii.oki.co.jp (s24c46.dm1.oii.oki.co.jp [172.26.76.96]) by s111h119.dm1.oii.oki.co.jp (Postfix) with ESMTP id 7B657398006; Fri, 20 May 2011 13:51:00 +0900 (JST) Received: from PC17099 (t102l39.dm1.oii.oki.co.jp [10.55.78.39]) by s24c46.dm1.oii.oki.co.jp (Postfix) with ESMTP id 5C07D30F41D; Fri, 20 May 2011 13:51:00 +0900 (JST) From: "Yasubumi CHIMURA" To: "'Miguel A. Garcia'" References: <4DC791E0.7010908@ericsson.com> <4DC8D232.8000501@ericsson.com> <646F70073B3B490EA5D77F7C2C70C15E@power.oki.co.jp> <4DD4C70D.3050901@ericsson.com> Date: Fri, 20 May 2011 13:51:00 +0900 Message-ID: <9F97D3180DE140C59E3E8A93238D1858@power.oki.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 In-Reply-To: <4DD4C70D.3050901@ericsson.com> Thread-Index: AcwV9p+PobRPLI7sQ0aEoDCHtjNzfwAsonvg Cc: 'mmusic' , 'OKUMURA Shinji' , "'DRAGE, Keith \(Keith\)'" , 'Flemming Andreasen' Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 04:51:03 -0000 Hi Miguel, Thank you for your support about Draft of "image" for T.38 SDP. I agree your opinion. Best Regards, Yasu Chimura -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: Thursday, May 19, 2011 4:30 PM To: Yasubumi CHIMURA Cc: 'DRAGE, Keith (Keith)'; 'mmusic'; 'Flemming Andreasen'; 'Noriyuki SATO'; 'OKUMURA Shinji'; Gonzalo Salgueiro Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration Hi Yasu, My opinions, as an individual, below. On 18/05/2011 13:54, Yasubumi CHIMURA wrote: > Hi Miguel, > > I'm Chimura from OKI-J and CIAJ. > > I have one comment about draft-salgueiro-mmusic-image-iana-registration. > > RFC4566 described the procedure following; > RFC4566 p24 > The media type registration SHOULD define the packet > format for use with UDP transport. > ... > For media using other transport protocols, the field is > protocol specific. Rules for interpretation of the sub- > field MUST be defined when registering new protocols (see Section > 8.2.2). > > Therefore, if it use without UDP transport in m=image, should be describe > the packet format. > > And, if it use with UDP transport in m=image, should be describe the > definition of fmt and the attribution(a=) of SDP. I get the point, I belive. But I doubt we can just define a single packet format for sending any type of "image" media types. I guess we should say that T38 is one of the possible packet formats, and the full packet format description when using UDP transport is described in ITU-T T.38 recommendation. If in the future, there are additional formats of "image" with UDP, then a different specification should describe the packet format. Also, notice that T38 allows several transport protocols, including TCP, UDP, UDPTL, RTP. My suggestion is that the registration of the media type "image" delegates the packet format description over UDP to the media format description. Also, the draft should say that, when T38 is the media format, ITU-T T.38 contains the packet format description. BR, Miguel > > Best Regards, > > Yasu Chimura > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Tuesday, May 10, 2011 2:51 PM > To: DRAGE, Keith (Keith) > Cc: mmusic; Flemming Andreasen; 'Yasubumi CHIMURA' > Subject: Re: [MMUSIC] Process for > draft-salgueiro-mmusic-image-iana-registration > > Hi Keith, > > An individual document will not go through an official WGLC, but I guess > the working group can always get a closer look at it before the author > submitting it as an individual submission. > > /Miguel > > On 09/05/2011 17:50, DRAGE, Keith (Keith) wrote: >> If you are going to WGLC this document, surely you might as well make this > a working group draft. >> >> If it is AD sponsored, then the first question is sufficient - look at it > now, and then it goes for a four week IETF last call. >> >> Keith >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >>> Of Miguel A. Garcia >>> Sent: 09 May 2011 08:04 >>> To: mmusic >>> Cc: Flemming Andreasen; 'Yasubumi CHIMURA' >>> Subject: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana- >>> registration >>> >>> In relation with the registration of the SDP 'image' media type, we are >>> going to try to expedite this draft, since it is a very simple missing >>> registration. >>> >>> The idea is to progress the draft as an individual submission, >>> AD-sponsored draft. So, the chairs would like the working group to take a >>> closer look at it (it is a short one), so that we can go to WGLC in a >>> short time frame. >>> >>> So please, send comments as soon as possible. Do not wait to the WGLC. >>> >>> BR, >>> >>> Miguel >>> -- >>> Miguel A. Garcia >>> +34-91-339-3608 >>> Ericsson Spain >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From gsalguei@cisco.com Fri May 20 01:56:38 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A26E0734 for ; Fri, 20 May 2011 01:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUz6iI8IurLI for ; Fri, 20 May 2011 01:56:37 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3761FE072C for ; Fri, 20 May 2011 01:56:37 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4K8uXbK008931; Fri, 20 May 2011 04:56:34 -0400 (EDT) Received: from rtp-vpn2-348.cisco.com (rtp-vpn2-348.cisco.com [10.82.241.92]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4K8uExw008044; Fri, 20 May 2011 04:56:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-66--990423980 From: Gonzalo Salgueiro In-Reply-To: <9F97D3180DE140C59E3E8A93238D1858@power.oki.co.jp> Date: Fri, 20 May 2011 04:56:14 -0400 Message-Id: <16927C3E-74B8-4862-924C-A23A2FAFC271@cisco.com> References: <4DC791E0.7010908@ericsson.com> <4DC8D232.8000501@ericsson.com> <646F70073B3B490EA5D77F7C2C70C15E@power.oki.co.jp> <4DD4C70D.3050901@ericsson.com> <9F97D3180DE140C59E3E8A93238D1858@power.oki.co.jp> To: Yasubumi CHIMURA , "Miguel A. Garcia" X-Mailer: Apple Mail (2.1084) Cc: OKUMURA Shinji , mmusic Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 08:56:38 -0000 --Apple-Mail-66--990423980 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yasu & Miguel -=20 I also completely agree with Miguel's assessment that there is no value = in describing the packet format that is already well defined in T.38. I have submitted an -02 version capturing the comments from this = discussion.=20 Please provide any feedback regarding the latest version of this draft. Regards, Gonzalo =20 On May 20, 2011, at 12:51 AM, Yasubumi CHIMURA wrote: > Hi Miguel, >=20 > Thank you for your support about Draft of "image" for T.38 SDP. > I agree your opinion. >=20 > Best Regards, >=20 > Yasu Chimura > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]=20 > Sent: Thursday, May 19, 2011 4:30 PM > To: Yasubumi CHIMURA > Cc: 'DRAGE, Keith (Keith)'; 'mmusic'; 'Flemming Andreasen'; 'Noriyuki = SATO'; > 'OKUMURA Shinji'; Gonzalo Salgueiro > Subject: Re: [MMUSIC] Process for > draft-salgueiro-mmusic-image-iana-registration >=20 > Hi Yasu, >=20 > My opinions, as an individual, below. >=20 > On 18/05/2011 13:54, Yasubumi CHIMURA wrote: >> Hi Miguel, >>=20 >> I'm Chimura from OKI-J and CIAJ. >>=20 >> I have one comment about = draft-salgueiro-mmusic-image-iana-registration. >>=20 >> RFC4566 described the procedure following; >> RFC4566 p24 >> The media type registration SHOULD define the packet >> format for use with UDP transport. >> ... >> For media using other transport protocols, the field is >> protocol specific. Rules for interpretation of the sub- >> field MUST be defined when registering new protocols (see = Section >> 8.2.2). >>=20 >> Therefore, if it use without UDP transport in m=3Dimage, should be = describe >> the packet format. >>=20 >> And, if it use with UDP transport in m=3Dimage, should be describe = the >> definition of fmt and the attribution(a=3D) of SDP. >=20 > I get the point, I belive. But I doubt we can just define a single = packet=20 > format for sending any type of "image" media types. I guess we should = say=20 > that T38 is one of the possible packet formats, and the full packet=20 > format description when using UDP transport is described in ITU-T T.38=20= > recommendation. If in the future, there are additional formats of = "image"=20 > with UDP, then a different specification should describe the packet = format. >=20 > Also, notice that T38 allows several transport protocols, including = TCP,=20 > UDP, UDPTL, RTP. >=20 > My suggestion is that the registration of the media type "image"=20 > delegates the packet format description over UDP to the media format=20= > description. Also, the draft should say that, when T38 is the media=20 > format, ITU-T T.38 contains the packet format description. >=20 > BR, >=20 > Miguel >>=20 >> Best Regards, >>=20 >> Yasu Chimura >> -----Original Message----- >> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >> Sent: Tuesday, May 10, 2011 2:51 PM >> To: DRAGE, Keith (Keith) >> Cc: mmusic; Flemming Andreasen; 'Yasubumi CHIMURA' >> Subject: Re: [MMUSIC] Process for >> draft-salgueiro-mmusic-image-iana-registration >>=20 >> Hi Keith, >>=20 >> An individual document will not go through an official WGLC, but I = guess >> the working group can always get a closer look at it before the = author >> submitting it as an individual submission. >>=20 >> /Miguel >>=20 >> On 09/05/2011 17:50, DRAGE, Keith (Keith) wrote: >>> If you are going to WGLC this document, surely you might as well = make > this >> a working group draft. >>>=20 >>> If it is AD sponsored, then the first question is sufficient - look = at it >> now, and then it goes for a four week IETF last call. >>>=20 >>> Keith >>>=20 >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf >>>> Of Miguel A. Garcia >>>> Sent: 09 May 2011 08:04 >>>> To: mmusic >>>> Cc: Flemming Andreasen; 'Yasubumi CHIMURA' >>>> Subject: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana- >>>> registration >>>>=20 >>>> In relation with the registration of the SDP 'image' media type, we = are >>>> going to try to expedite this draft, since it is a very simple = missing >>>> registration. >>>>=20 >>>> The idea is to progress the draft as an individual submission, >>>> AD-sponsored draft. So, the chairs would like the working group to = take > a >>>> closer look at it (it is a short one), so that we can go to WGLC in = a >>>> short time frame. >>>>=20 >>>> So please, send comments as soon as possible. Do not wait to the = WGLC. >>>>=20 >>>> BR, >>>>=20 >>>> Miguel >>>> -- >>>> Miguel A. Garcia >>>> +34-91-339-3608 >>>> Ericsson Spain >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain --Apple-Mail-66--990423980 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yasu = & Miguel - 

I also completely agree with = Miguel's assessment that there is no value in describing the packet = format that is already well defined in T.38.

I = have submitted an -02 version capturing the comments from this = discussion. 

Please provide any feedback = regarding the latest version of this = draft.

Regards,

Gonzalo<= /div>
 
On May 20, 2011, at 12:51 AM, Yasubumi = CHIMURA wrote:

Hi Miguel,

Thank you for your support about = Draft of "image" for T.38 SDP.
I agree your opinion.

Best = Regards,

Yasu Chimura
-----Original Message-----
From: = Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
Sent: = Thursday, May 19, 2011 4:30 PM
To: Yasubumi CHIMURA
Cc: 'DRAGE, = Keith (Keith)'; 'mmusic'; 'Flemming Andreasen'; 'Noriyuki = SATO';
'OKUMURA Shinji'; Gonzalo Salgueiro
Subject: Re: [MMUSIC] = Process for
draft-salgueiro-mmusic-image-iana-registration

Hi = Yasu,

My opinions, as an individual, below.

On 18/05/2011 = 13:54, Yasubumi CHIMURA wrote:
Hi = Miguel,

I'm Chimura = from OKI-J and CIAJ.

I have one = comment about = draft-salgueiro-mmusic-image-iana-registration.

RFC4566 = described the procedure following;
RFC4566 p24
The media = type registration SHOULD define the packet
= format for use with UDP transport.
= ...
For media = using other transport protocols, the<fmt>  field = is
protocol = specific.  Rules for interpretation of the<fmt> =  sub-
field = MUST be defined when registering new protocols (see = Section
= 8.2.2).

Therefore, if = it use without UDP transport in m=3Dimage, should be = describe
the packet = format.

And, if it use = with UDP transport in m=3Dimage, should be describe = the
definition of fmt and the = attribution(a=3D) of SDP.

I get the point, I belive. = But I doubt we can just define a single packet
format for sending = any type of "image" media types. I guess we should say
that T38 is = one of the possible packet formats, and the full packet
format = description when using UDP transport is described in ITU-T T.38 =
recommendation. If in the future, there are additional formats of = "image"
with UDP, then a different specification should describe the = packet format.

Also, notice that T38 allows several transport = protocols, including TCP,
UDP, UDPTL, RTP.

My suggestion is = that the registration of the media type "image"
delegates the packet = format description over UDP to the media format
description. Also, = the draft should say that, when T38 is the media
format, ITU-T T.38 = contains the packet format description.

BR,

=    Miguel

Best = Regards,

Yasu = Chimura
-----Original = Message-----
From: Miguel A. = Garcia [mailto:Miguel.A.Garcia@ericsson.com]
Sent: Tuesday, May 10, 2011 2:51 = PM
To: DRAGE, Keith = (Keith)
Cc: mmusic; Flemming = Andreasen; 'Yasubumi CHIMURA'
Subject: Re: [MMUSIC] Process = for
draft-salgueiro-mmusic-image-iana-registration

Hi= Keith,

An individual = document will not go through an official WGLC, but I = guess
the working group can = always get a closer look at it before the = author
submitting it as an = individual submission.

/Miguel

On 09/05/2011 = 17:50, DRAGE, Keith (Keith) wrote:
If you are going to WGLC this = document, surely you might as well = make
this
a = working group draft.

If it is AD sponsored, then the = first question is sufficient - look at = it
now, and then = it goes for a four week IETF last call.

Keith

-----Original = Message-----
From: = mmusic-bounces@ietf.org = [mailto:mmusic-bounces@ietf.org] On = Behalf
Of = Miguel A. Garcia
Sent: = 09 May 2011 08:04
To: = mmusic
Cc: = Flemming Andreasen; 'Yasubumi = CHIMURA'
Subject:= [MMUSIC] Process for = draft-salgueiro-mmusic-image-iana-
registration

In = relation with the registration of the SDP 'image' media type, we = are
going = to try to expedite this draft, since it is a very simple = missing
registration.

The = idea is to progress the draft as an individual = submission,
AD-sponsored draft. So, the chairs would like the working = group to take
a
closer = look at it (it is a short one), so that we can go to WGLC in = a
short = time frame.

So = please, send comments as soon as possible. Do not wait to the = WGLC.

BR,

=       Miguel
--
Miguel = A. Garcia
+34-91-339-3608
Ericsson = Spain
_______________________________________________
mmusic mailing = list
mmusic@ietf.org
https://www.ietf.org= /mailman/listinfo/mmusic


--
Miguel A. = Garcia
+34-91-339-3608
Ericsson = Spain

= --Apple-Mail-66--990423980-- From ari.keranen@nomadiclab.com Fri May 20 04:57:55 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA567E070F; Fri, 20 May 2011 04:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXQOGxH40Ke5; Fri, 20 May 2011 04:57:54 -0700 (PDT) Received: from gw.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 054A5E065D; Fri, 20 May 2011 04:57:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 7AE1E4E6D8; Fri, 20 May 2011 14:57:46 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFRlRadVFuXL; Fri, 20 May 2011 14:57:44 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 7D8984E6BD; Fri, 20 May 2011 14:57:44 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: <4DD586F7.3080407@cisco.com> Date: Fri, 20 May 2011 14:57:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <468F4F6E-7D7A-46AD-9694-ABC54B75F357@nomadiclab.com> References: <4DA86A44.9040909@cisco.com> <4DC89DB6.70008@cisco.com> <56FA6861-542E-422F-AEE2-5B987014E8A4@nomadiclab.com> <4DCC4B8C.9040104@cisco.com> <030CB46E-A5FD-49C1-A7F4-B3329CD04EB5@nomadiclab.com> <4DD586F7.3080407@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.1084) Cc: mmusic-chairs@ietf.org, mmusic , draft-ietf-mmusic-ice-tcp@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-tcp-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 11:57:55 -0000 Thanks for your review Flemming! I'll wait for a while for comments on = the TCP amplification attack and then submit a new version with the = changes we have discussed. Cheers, Ari On May 20, 2011, at 12:09 AM, Flemming Andreasen wrote: > Thanks Ari >=20 > This addresses all of my comments (modulo any additional suggestions = for better ways of mitigating the TCP amplification attack).=20 >=20 > -- Flemming=20 >=20 >=20 > On 5/19/11 10:40 AM, Ari Keranen wrote: >> On May 13, 2011, at 12:05 AM, Flemming Andreasen wrote: >> > On 5/11/11 11:55 AM, Ari Keranen wrote: >> >> Hi Flemming, >> >> >> >> Thanks for the thorough review! See inline. >> >> >> >> On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote: >> >> [...] >> >> > - Section 7.1, third paragraph >> >> > >> >> > If the TCP connection cannot be established, the check is = considered >> >> > to have failed, and a full-mode agent MUST update the pair = state to >> >> > Failed in the check list. >> >> > >> >> > a) How long do you wait before determining it cannot be = established ? Need some considerations around this >> >> >> >> I have considered this as an implementation/platform detail: you = do connect() and wait until it succeeds or fails. Or do you have = suggestions what additional to recommend here? >> >> >> >> >> > Does RFC 5389 Section 7.2.2 simply apply directly here and hence we = should just reference that ? >>=20 >> That's probably the easiest fix. I'll add a reference to that =10(after= the sentence you quoted): "See Section 7.2.2 in [RFC5389] for more = details on STUN over TCP". >>=20 >> > >> >> > b) Also, how fast do you attempt to establish additional TCP = connections ? Timer Ta considerations would seem to apply to the TCP = connection establishment here. >> >> >> >> Yes, the agents pace the start of the checks like for UDP. The end = of section 4.1 says "Like its UDP counterparts, TCP-based STUN = transactions are paced out at one every Ta seconds." It could be a bit = confusing that the comment is under "Gathering candidates" section, but = it refers to all STUN transactions. >> >> >> > I think we should mention it in Section 7.1, however looking at it = again, I assume we simply following Section 5.8 from RFC 5245 = (Scheduling Checks), and hence a reference to that effect would suffice. >>=20 >> OK; that's actually true for the whole document (5245 procedures are = followed unless said otherwise), but I guess it makes sense to make this = more explicit here too. Right before 7.1 it says now (added the = reference part between commas): >>=20 >> [...] The TCP candidate pairs are in the same >> checklist with the UDP candidate pairs and they are scheduled for >> connectivity checks, as described in Section 5.8 in [RFC5245], = based >> on the priority order. >>=20 >> >> >> >> > - Section 11.1 >> >> > The section seems to be written under the assumption that both = sides are full ICE Implementations. Need to consider lite = implementations as well. >> >> >> >> This seemed OK to me. What would you change here to accommodate = also lite agents? >> >> >> > >> > You have the following text for example >> > >> > If the TCP connection is established, the framing of RFC 4571 is >> > utilized. If the agent opened the connection, it MUST send a = STUN >> > connectivity check.=20 >> > >> > >> > That latter sentence would presumably only apply if the agent is a = full implementation. >>=20 >> True, but a lite agent would not open (initiate) a connection if it = has only passive candidates. The default candidate complicates this a = bit though; I added "and is a full agent" clarification there to make it = more clear. >>=20 >> > Similarly >> > >> > If an agent receives a connectivity check after re- >> > establishment of the connection, it MUST generate a triggered = check >> > over that connection in response if it has not already sent a = check. >> > Once an agent has sent a check and received a successful = response, >> > the connection is considered Valid and media can be sent (which >> > includes a TLS or DTLS-SRTP session resumption or restart) >> > >> > seems to assume full ICE implementations. >>=20 >> True. I changed that into "If a full agent [...]". >>=20 >> >> >> >> > - Section 12 >> >> > I believe there is a TCP amplification attack similar to the = STUN amplification attack that requires consideration, since the TCP = connection is established prior to any STUN/ICE checks and involves TCP = state creation on the part of the attacked party. >> >> >> >> I guess you're right. We should document that, but any ideas for = mitigation? >> >> >> > >> > I'm not sure - maybe we can limit the number of outstanding TCP = connection attempts to the same IP-address ? It would probably be = worthwhile asking some of the security experts here. >>=20 >> That should work. Anyway, I sent a separate mail about this to the = list. >>=20 >> [..] >> > >> >> > - Section 3, Figure 1 >> >> > It would be helpful to either expand the figure to cover the = non-(D)TLS case as well or have another figure showing that for = comparison >> >> >> >> Do we really need one, considering the non-(D)TLS case is fairly = trivial, right? The "strangeness" in the (D)TLS case comes from the fact = that STUN is used outside of the (D)TLS connection. >> >> >> >> Although, the figure caption should be updated to reflect the fact = that this is the (D)TLS case; now it says "ICE TCP Stack with (D)TLS". >> >> >> >> >> > You don't *need* it, but it would have been helpful to me the first = time I read it at least. >>=20 >> OK, I'll see how combining those two in the same figure works out. >>=20 >> > >> >> >> >> > - Section 4.2 >> >> > >> >> > The direction-pref MUST be between 0 and 7, with 7 being the = most >> >> > preferred. The other-pref MUST be between 0 and 8191, with = 8191 >> >> > being the most preferred. >> >> > >> >> > Rephrase to make clear that 0 and 8191 (presumably) are both = valid values in these ranges. >> >> >> >> OK, now it says: >> >> >> >> The direction-pref MUST be between 0 and 7 (inclusive), with 7 = being >> >> the most preferred. The other-pref MUST be between 0 and 8191 >> >> (inclusive), with 8191 being the most preferred. >> >> >> >> >> > I'd say "both inclusive". >>=20 >> Fixed. >>=20 >> > >> >> >> >> >> >> > - Section 4.5 >> >> > >> >> > The connection-address and port encoded into the candidate = attribute >> >> > for active candidates MUST be set to the IP address that will = be used >> >> > for the attempt, but the port(s) MUST be set to 9 (i.e., = Discard). >> >> > >> >> > - Delete the "and port" part. >> >> >> >> Why? The "port" refers to the "port" and "rel-port" parts in the = candidate-attribute. >> >> >> >> >> > >> > The sentence reads >> > >> > The connection-address and port encoded into the candidate = attribute >> > for active candidates MUST be set to the IP address that will be = used >> > for the attempt, >> > >> > >> > You can only set the connection-address to the IP address, not the = port. It's a nit. >>=20 >> Ah, yes, good catch. Actually, it should say "[...] MUST be set to = the IP address and port" (fixed). >>=20 >>=20 >> >> >> >> > - Section 15.2 >> >> > RFC 3261, 5389, 5766, and 6062 should all be normative rather = informative. >> >> >> >> Fixed the first two, but 5776 (TURN) and 6062 (TURN TCP) are = intentionally informative since TURN is just one of the possible = techniques for relaying. >> >> >> >> >> > Except from = http://www.rfc-editor.org/rfc-editor/instructions2authors.txt >> > >> > >> > Within an RFC, references to other documents fall into two = general >> > categories: "normative" and "informative". Normative = references >> > specify documents that must be read to understand or = implement the >> > technology in the new RFC, or whose technology must be = present for >> > the technology in the new RFC to work. An informative = reference >> > is not normative; rather, it provides only additional = information. >> > For example, an informative reference might provide = background or >> > historical information. Material in an informative reference = is >> > not required to implement the technology in the RFC. >> > >> > >> > In other words, just because you don't mandata the use of TURN = doesn't automatically turn it into an informative reference (as I've = been told >> > >> > I think the TURN text in e.g. Section 1, Section 4.1, Section 11.2 = etc makes RFC 5766 a Normative reference per the above. RFC 6062 is = perhaps more debatable. >>=20 >> OK. The idea was to have TURN "at the same level" as the other = techniques and that's why it is informative, like the rest. That said, = it's true that TURN has a bit of special attention in the text and I'm = OK with moving 5766 to normative. >>=20 >>=20 >> Cheers, >> Ari >>=20 From dwing@cisco.com Mon May 23 11:25:56 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2F8E06A5 for ; Mon, 23 May 2011 11:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.455 X-Spam-Level: X-Spam-Status: No, score=-110.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn3phcJsYB5t for ; Mon, 23 May 2011 11:25:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id E26EBE069E for ; Mon, 23 May 2011 11:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2046; q=dns/txt; s=iport; t=1306175155; x=1307384755; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=MN5kIq7I2LKfhlNwyYay2Y6sd2BF6nWxTUXINktiSYE=; b=PzPupVCX1th9LTC2Y7frJ58v3GipeHMKOWMYOX4Ztxn/+qhNKMU4jcG1 NmCtR32Fgm6RrccreL0wEZlsbCv7jvzFzaNCFZO1Vu7u2YWlHbdF1KVjX 3fh1a5i265DV9MXLTJSXGI8PeLSX+EomxHinBj88/7HFRHSUNx41hm8M9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcBABWm2k2rRDoI/2dsb2JhbACXZYFkjF53iHCeX51JhhkEhlCYVg X-IronPort-AV: E=Sophos;i="4.65,257,1304294400"; d="scan'208";a="452777563" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 23 May 2011 18:25:53 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4NIPqdp022280; Mon, 23 May 2011 18:25:53 GMT From: "Dan Wing" To: "'Ari Keranen'" , "'mmusic WG'" References: In-Reply-To: Date: Mon, 23 May 2011 11:25:51 -0700 Message-ID: <002901cc1976$d8b86420$8a292c60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwWMTVHlw6W/OqcQkWqGOfLzhLoTQDRRjrA Content-Language: en-us Subject: Re: [MMUSIC] ICE TCP and TCP amplification attack (mitigation) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 18:25:56 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Ari Keranen > Sent: Thursday, May 19, 2011 7:29 AM > To: mmusic WG > Subject: [MMUSIC] ICE TCP and TCP amplification attack (mitigation) > > Hi all, > > Flemming identified a possible TCP amplification attack in ICE TCP: > > On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote: > > - Section 12 > > I believe there is a TCP amplification attack similar to the STUN > amplification attack that requires consideration, since the TCP > connection is established prior to any STUN/ICE checks and involves TCP > state creation on the part of the attacked party. > > That is, an attacker could put in the SDP offer a set of passive > reflexive candidates with the address of the victim and the answerer > would make a bunch of TCP connections towards the victim. That attack is inherent to ICE itself, and not the fault or cause of the TURN-TCP specification. If text is added to TURN-TCP, it would be nice to couch it with something like: A STUN amplification attack is described in Section 18.5.2 of [RFC5245], but unfortunately that specification did not describe how [RFC5245] can also be used to launch a TCP amplification attack. and the describe how TURN-TCP is but one way the TCP amplification could be launched. The other way is that RFC5245 could be used without TURN-TCP. > A possible mitigation, as Flemming suggested, would be to limit the > number of outstanding TCP connection attempts to the same IP-address. > That sounds reasonable to me, since having many (un-frozen) candidates > from the same IP address seem unlikely anyway, but are there any other > ideas? That sounds like a good approach. I wonder if Errata should be raised against RFC5245, instead or in addition? -d > > > Cheers, > Ari > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From kpfleming@digium.com Mon May 23 12:51:02 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C857CE0809 for ; Mon, 23 May 2011 12:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5N34MDXPV9G for ; Mon, 23 May 2011 12:51:01 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1C6E07F1 for ; Mon, 23 May 2011 12:51:01 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1QOb9Y-0007d2-7v for mmusic@ietf.org; Mon, 23 May 2011 14:51:00 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 3927ED82AC for ; Mon, 23 May 2011 14:51:00 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW-YZxKA1xuP for ; Mon, 23 May 2011 14:50:59 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 7C875D82A3 for ; Mon, 23 May 2011 14:50:59 -0500 (CDT) Message-ID: <4DDABAA2.2090108@digium.com> Date: Mon, 23 May 2011 14:50:58 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: mmusic@ietf.org References: <4DC791E0.7010908@ericsson.com> <4DC8D232.8000501@ericsson.com> <646F70073B3B490EA5D77F7C2C70C15E@power.oki.co.jp> <4DD4C70D.3050901@ericsson.com> <9F97D3180DE140C59E3E8A93238D1858@power.oki.co.jp> <16927C3E-74B8-4862-924C-A23A2FAFC271@cisco.com> In-Reply-To: <16927C3E-74B8-4862-924C-A23A2FAFC271@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 19:51:02 -0000 On 05/20/2011 03:56 AM, Gonzalo Salgueiro wrote: > Yasu & Miguel - > > I also completely agree with Miguel's assessment that there is no value > in describing the packet format that is already well defined in T.38. > > I have submitted an -02 version capturing the comments from this > discussion. > > Please provide any feedback regarding the latest version of this draft. I don't think that the comment raised here is exactly accurate. The stipulation quoted is from the definition of the '' field of the Media Description ('m' line). This is in reference to 'media formats', and only applies when the '' field is 'udp'. For T.38, the '' field is 'udptl', not 'udp', so this stipulation does not apply. In addition, even if the field were 'udp', 'image' is a top-level content type, not a value for the '' field. An SDP description of a T.38 session would have an '' value of 't38', which is defined to be valid by the T.38 recommendation itself. Interestingly, IANA has 'udptl' listed in the SDP parameters registry for 'proto', with the Reference being T.38... but RFC 4566 states that protocol registrations must refer to RFCs that describe the protocol, not documents from other SDOs :-) > > Regards, > > Gonzalo > > On May 20, 2011, at 12:51 AM, Yasubumi CHIMURA wrote: > >> Hi Miguel, >> >> Thank you for your support about Draft of "image" for T.38 SDP. >> I agree your opinion. >> >> Best Regards, >> >> Yasu Chimura >> -----Original Message----- >> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >> Sent: Thursday, May 19, 2011 4:30 PM >> To: Yasubumi CHIMURA >> Cc: 'DRAGE, Keith (Keith)'; 'mmusic'; 'Flemming Andreasen'; 'Noriyuki >> SATO'; >> 'OKUMURA Shinji'; Gonzalo Salgueiro >> Subject: Re: [MMUSIC] Process for >> draft-salgueiro-mmusic-image-iana-registration >> >> Hi Yasu, >> >> My opinions, as an individual, below. >> >> On 18/05/2011 13:54, Yasubumi CHIMURA wrote: >>> Hi Miguel, >>> >>> I'm Chimura from OKI-J and CIAJ. >>> >>> I have one comment about draft-salgueiro-mmusic-image-iana-registration. >>> >>> RFC4566 described the procedure following; >>> RFC4566 p24 >>> The media type registration SHOULD define the packet >>> format for use with UDP transport. >>> ... >>> For media using other transport protocols, the field is >>> protocol specific. Rules for interpretation of the sub- >>> field MUST be defined when registering new protocols (see Section >>> 8.2.2). >>> >>> Therefore, if it use without UDP transport in m=image, should be describe >>> the packet format. >>> >>> And, if it use with UDP transport in m=image, should be describe the >>> definition of fmt and the attribution(a=) of SDP. >> >> I get the point, I belive. But I doubt we can just define a single packet >> format for sending any type of "image" media types. I guess we should say >> that T38 is one of the possible packet formats, and the full packet >> format description when using UDP transport is described in ITU-T T.38 >> recommendation. If in the future, there are additional formats of "image" >> with UDP, then a different specification should describe the packet >> format. >> >> Also, notice that T38 allows several transport protocols, including TCP, >> UDP, UDPTL, RTP. >> >> My suggestion is that the registration of the media type "image" >> delegates the packet format description over UDP to the media format >> description. Also, the draft should say that, when T38 is the media >> format, ITU-T T.38 contains the packet format description. >> >> BR, >> >> Miguel >>> >>> Best Regards, >>> >>> Yasu Chimura >>> -----Original Message----- >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>> Sent: Tuesday, May 10, 2011 2:51 PM >>> To: DRAGE, Keith (Keith) >>> Cc: mmusic; Flemming Andreasen; 'Yasubumi CHIMURA' >>> Subject: Re: [MMUSIC] Process for >>> draft-salgueiro-mmusic-image-iana-registration >>> >>> Hi Keith, >>> >>> An individual document will not go through an official WGLC, but I guess >>> the working group can always get a closer look at it before the author >>> submitting it as an individual submission. >>> >>> /Miguel >>> >>> On 09/05/2011 17:50, DRAGE, Keith (Keith) wrote: >>>> If you are going to WGLC this document, surely you might as well make >> this >>> a working group draft. >>>> >>>> If it is AD sponsored, then the first question is sufficient - look >>>> at it >>> now, and then it goes for a four week IETF last call. >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org >>>>> [mailto:mmusic-bounces@ietf.org] On Behalf >>>>> Of Miguel A. Garcia >>>>> Sent: 09 May 2011 08:04 >>>>> To: mmusic >>>>> Cc: Flemming Andreasen; 'Yasubumi CHIMURA' >>>>> Subject: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana- >>>>> registration >>>>> >>>>> In relation with the registration of the SDP 'image' media type, we are >>>>> going to try to expedite this draft, since it is a very simple missing >>>>> registration. >>>>> >>>>> The idea is to progress the draft as an individual submission, >>>>> AD-sponsored draft. So, the chairs would like the working group to take >> a >>>>> closer look at it (it is a short one), so that we can go to WGLC in a >>>>> short time frame. >>>>> >>>>> So please, send comments as soon as possible. Do not wait to the WGLC. >>>>> >>>>> BR, >>>>> >>>>> Miguel >>>>> -- >>>>> Miguel A. Garcia >>>>> +34-91-339-3608 >>>>> Ericsson Spain >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From gsalguei@cisco.com Mon May 23 15:50:38 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA39E06BA for ; Mon, 23 May 2011 15:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5iTfk0UIjlV for ; Mon, 23 May 2011 15:50:36 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2F5E0688 for ; Mon, 23 May 2011 15:50:36 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4NMoXOE010154; Mon, 23 May 2011 18:50:33 -0400 (EDT) Received: from dhcp-64-102-211-8.cisco.com (dhcp-64-102-211-8.cisco.com [64.102.211.8]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4NMoVjR024995; Mon, 23 May 2011 18:50:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-35--681166214 From: Gonzalo Salgueiro In-Reply-To: <4DDABAA2.2090108@digium.com> Date: Mon, 23 May 2011 18:50:31 -0400 Message-Id: <2EAE4432-8B25-42B9-9536-3EF824611A4A@cisco.com> References: <4DC791E0.7010908@ericsson.com> <4DC8D232.8000501@ericsson.com> <646F70073B3B490EA5D77F7C2C70C15E@power.oki.co.jp> <4DD4C70D.3050901@ericsson.com> <9F97D3180DE140C59E3E8A93238D1858@power.oki.co.jp> <16927C3E-74B8-4862-924C-A23A2FAFC271@cisco.com> <4DDABAA2.2090108@digium.com> To: "Kevin P. Fleming" X-Mailer: Apple Mail (2.1084) Cc: mmusic Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 22:50:38 -0000 --Apple-Mail-35--681166214 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Kevin -=20 Thanks for reviewing. See Inline... On May 23, 2011, at 3:50 PM, Kevin P. Fleming wrote: > On 05/20/2011 03:56 AM, Gonzalo Salgueiro wrote: >> Yasu & Miguel - >>=20 >> I also completely agree with Miguel's assessment that there is no = value >> in describing the packet format that is already well defined in T.38. >>=20 >> I have submitted an -02 version capturing the comments from this >> discussion. >>=20 >> Please provide any feedback regarding the latest version of this = draft. >=20 > I don't think that the comment raised here is exactly accurate. >=20 > The stipulation quoted is from the definition of the '' field of = the Media Description ('m' line). This is in reference to 'media = formats', and only applies when the '' field is 'udp'. For T.38, = the '' field is 'udptl', not 'udp', so this stipulation does not = apply. In addition, even if the field were 'udp', 'image' is a top-level = content type, not a value for the '' field. An SDP description of a = T.38 session would have an '' value of 't38', which is defined to = be valid by the T.38 recommendation itself. You're right. In fact, as a result of knowing the T.38 protocol was = udptl, I was intentionally broad in my statements relating to not = providing packet formats for ANY of the valid T.38 transport protocols. = Since we are in agreement that this registration is not a candidate for = consideration of packet formats as requested in Section 5.14 of RFC4566, = do I completely remove the innocuous item (#7 in Section 3 of = draft-salgueiro-mmusic-image-iana-registration-03) stating that packet = formats are not provided in this draft because it is instead delegated = to T.38? Or is it viewed as useful statement that adds clarity and = should remain in the draft? I personally don't have a preference either way. >=20 > Interestingly, IANA has 'udptl' listed in the SDP parameters registry = for 'proto', with the Reference being T.38... but RFC 4566 states that = protocol registrations must refer to RFCs that describe the protocol, = not documents from other SDOs :-) >=20 Yikes, that isn't good. In this case a pointer to T.38 is the right = thing IMO, so I think this is something that can easily be amended in = 4566bis. Copying Ali for awareness. Regards, Gonzalo >>=20 >> Regards, >>=20 >> Gonzalo >>=20 >> On May 20, 2011, at 12:51 AM, Yasubumi CHIMURA wrote: >>=20 >>> Hi Miguel, >>>=20 >>> Thank you for your support about Draft of "image" for T.38 SDP. >>> I agree your opinion. >>>=20 >>> Best Regards, >>>=20 >>> Yasu Chimura >>> -----Original Message----- >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>> Sent: Thursday, May 19, 2011 4:30 PM >>> To: Yasubumi CHIMURA >>> Cc: 'DRAGE, Keith (Keith)'; 'mmusic'; 'Flemming Andreasen'; = 'Noriyuki >>> SATO'; >>> 'OKUMURA Shinji'; Gonzalo Salgueiro >>> Subject: Re: [MMUSIC] Process for >>> draft-salgueiro-mmusic-image-iana-registration >>>=20 >>> Hi Yasu, >>>=20 >>> My opinions, as an individual, below. >>>=20 >>> On 18/05/2011 13:54, Yasubumi CHIMURA wrote: >>>> Hi Miguel, >>>>=20 >>>> I'm Chimura from OKI-J and CIAJ. >>>>=20 >>>> I have one comment about = draft-salgueiro-mmusic-image-iana-registration. >>>>=20 >>>> RFC4566 described the procedure following; >>>> RFC4566 p24 >>>> The media type registration SHOULD define the packet >>>> format for use with UDP transport. >>>> ... >>>> For media using other transport protocols, the field is >>>> protocol specific. Rules for interpretation of the sub- >>>> field MUST be defined when registering new protocols (see Section >>>> 8.2.2). >>>>=20 >>>> Therefore, if it use without UDP transport in m=3Dimage, should be = describe >>>> the packet format. >>>>=20 >>>> And, if it use with UDP transport in m=3Dimage, should be describe = the >>>> definition of fmt and the attribution(a=3D) of SDP. >>>=20 >>> I get the point, I belive. But I doubt we can just define a single = packet >>> format for sending any type of "image" media types. I guess we = should say >>> that T38 is one of the possible packet formats, and the full packet >>> format description when using UDP transport is described in ITU-T = T.38 >>> recommendation. If in the future, there are additional formats of = "image" >>> with UDP, then a different specification should describe the packet >>> format. >>>=20 >>> Also, notice that T38 allows several transport protocols, including = TCP, >>> UDP, UDPTL, RTP. >>>=20 >>> My suggestion is that the registration of the media type "image" >>> delegates the packet format description over UDP to the media format >>> description. Also, the draft should say that, when T38 is the media >>> format, ITU-T T.38 contains the packet format description. >>>=20 >>> BR, >>>=20 >>> Miguel >>>>=20 >>>> Best Regards, >>>>=20 >>>> Yasu Chimura >>>> -----Original Message----- >>>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>> Sent: Tuesday, May 10, 2011 2:51 PM >>>> To: DRAGE, Keith (Keith) >>>> Cc: mmusic; Flemming Andreasen; 'Yasubumi CHIMURA' >>>> Subject: Re: [MMUSIC] Process for >>>> draft-salgueiro-mmusic-image-iana-registration >>>>=20 >>>> Hi Keith, >>>>=20 >>>> An individual document will not go through an official WGLC, but I = guess >>>> the working group can always get a closer look at it before the = author >>>> submitting it as an individual submission. >>>>=20 >>>> /Miguel >>>>=20 >>>> On 09/05/2011 17:50, DRAGE, Keith (Keith) wrote: >>>>> If you are going to WGLC this document, surely you might as well = make >>> this >>>> a working group draft. >>>>>=20 >>>>> If it is AD sponsored, then the first question is sufficient - = look >>>>> at it >>>> now, and then it goes for a four week IETF last call. >>>>>=20 >>>>> Keith >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mmusic-bounces@ietf.org >>>>>> [mailto:mmusic-bounces@ietf.org] On Behalf >>>>>> Of Miguel A. Garcia >>>>>> Sent: 09 May 2011 08:04 >>>>>> To: mmusic >>>>>> Cc: Flemming Andreasen; 'Yasubumi CHIMURA' >>>>>> Subject: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana- >>>>>> registration >>>>>>=20 >>>>>> In relation with the registration of the SDP 'image' media type, = we are >>>>>> going to try to expedite this draft, since it is a very simple = missing >>>>>> registration. >>>>>>=20 >>>>>> The idea is to progress the draft as an individual submission, >>>>>> AD-sponsored draft. So, the chairs would like the working group = to take >>> a >>>>>> closer look at it (it is a short one), so that we can go to WGLC = in a >>>>>> short time frame. >>>>>>=20 >>>>>> So please, send comments as soon as possible. Do not wait to the = WGLC. >>>>>>=20 >>>>>> BR, >>>>>>=20 >>>>>> Miguel >>>>>> -- >>>>>> Miguel A. Garcia >>>>>> +34-91-339-3608 >>>>>> Ericsson Spain >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>=20 >>>=20 >>> -- >>> Miguel A. Garcia >>> +34-91-339-3608 >>> Ericsson Spain >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 > --=20 > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: = kpfleming > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail-35--681166214 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Kevin = - 

Thanks for reviewing. See = Inline...

On May 23, 2011, at 3:50 PM, Kevin P. = Fleming wrote:

On 05/20/2011 03:56 AM, Gonzalo Salgueiro = wrote:
Yasu & Miguel = -

I also completely agree with Miguel's assessment that = there is no value
in = describing the packet format that is already well defined in = T.38.

I have = submitted an -02 version capturing the comments from = this
discussion.

Please provide = any feedback regarding the latest version of this = draft.

I don't think that the comment raised here is = exactly accurate.

The stipulation quoted is from the definition = of the '<fmt>' field of the Media Description ('m' line). This is = in reference to 'media formats', and only applies when the = '<proto>' field is 'udp'. For T.38, the '<proto>' field is = 'udptl', not 'udp', so this stipulation does not apply. In addition, = even if the field were 'udp', 'image' is a top-level content type, not a = value for the '<fmt>' field. An SDP description of a T.38 session = would have an '<fmt>' value of 't38', which is defined to be valid = by the T.38 recommendation = itself.

You're right. In fact, as a = result of knowing the T.38 protocol was udptl, I was intentionally broad = in my statements relating to not providing packet formats for ANY of the = valid T.38 transport protocols. Since we are in agreement that this = registration is not a candidate for consideration of packet formats as = requested in Section 5.14 of RFC4566, do I completely remove the = innocuous item (#7 in Section 3 = of draft-salgueiro-mmusic-image-iana-registration-03) stating that = packet formats are not provided in this draft because it is instead = delegated to T.38? Or is it viewed as useful statement that adds clarity = and should remain in the draft?

I personally = don't have a preference either way.


Interestingly, IANA has 'udptl' listed in the SDP = parameters registry for 'proto', with the Reference being T.38... but = RFC 4566 states that protocol registrations must refer to RFCs that = describe the protocol, not documents from other SDOs = :-)

Yikes, that isn't good. In this case a = pointer to T.38 is the right thing IMO, so I think this is something = that can easily be amended in 4566bis. Copying Ali for = awareness.

Regards,

Gonz= alo


Regards,

Gonzalo

On May 20, = 2011, at 12:51 AM, Yasubumi CHIMURA wrote:

Hi Miguel,

Thank you for your support about = Draft of "image" for T.38 SDP.
I agree your = opinion.

Best = Regards,

Yasu = Chimura
-----Original = Message-----
From: Miguel A. Garcia = [mailto:Miguel.A.Garcia@ericsson.com]
Sent: Thursday, May 19, = 2011 4:30 PM
To: Yasubumi = CHIMURA
Cc: 'DRAGE, Keith (Keith)'; 'mmusic'; 'Flemming = Andreasen'; 'Noriyuki
SATO';
'OKUMURA Shinji'; Gonzalo = Salgueiro
Subject: Re: [MMUSIC] Process = for
draft-salgueiro-mmusic-image-iana-registration

Hi = Yasu,

My opinions, as an individual, = below.

On 18/05/2011 13:54, Yasubumi = CHIMURA wrote:
Hi = Miguel,

I'm = Chimura from OKI-J and = CIAJ.

I have = one comment about = draft-salgueiro-mmusic-image-iana-registration.

RFC4566 = described the procedure = following;
RFC4566 = p24
The = media type registration SHOULD define the = packet
format = for use with UDP = transport.
...
For = media using other transport protocols, the<fmt> field = is
protocol= specific. Rules for interpretation of the<fmt> = sub-
field = MUST be defined when registering new protocols (see = Section
8.2.2).

Therefore, if it use without UDP transport in m=3Dimage, = should be describe
the = packet format.

And, = if it use with UDP transport in m=3Dimage, should be describe = the
definition of fmt and the attribution(a=3D) of = SDP.

I get the point, I belive. But I = doubt we can just define a single = packet
format for sending any type of "image" media types. I = guess we should say
that T38 is one of the possible = packet formats, and the full = packet
format description when using UDP transport is described = in ITU-T T.38
recommendation. If in the = future, there are additional formats of = "image"
with UDP, then a different specification should describe = the packet
format.

Also, notice that T38 allows = several transport protocols, including = TCP,
UDP, UDPTL, RTP.

My suggestion is that the = registration of the media type = "image"
delegates the packet format description over UDP to the = media format
description. Also, the draft = should say that, when T38 is the = media
format, ITU-T T.38 contains the packet format = description.

BR,

Miguel

Best = Regards,

Yasu = Chimura
-----Original = Message-----
From: = Miguel A. Garcia = [mailto:Miguel.A.Garcia@ericsson.com]
Sent: Tuesday, May 10, 2011 2:51 = PM
To: = DRAGE, Keith = (Keith)
Cc: = mmusic; Flemming Andreasen; 'Yasubumi = CHIMURA'
Subject:= Re: [MMUSIC] Process = for
draft-salgueiro-mmusic-image-iana-registration

Hi = Keith,

An = individual document will not go through an official WGLC, but I = guess
the = working group can always get a closer look at it before the = author
submitting it as an individual = submission.

/Miguel

On = 09/05/2011 17:50, DRAGE, Keith (Keith) = wrote:
If you are going to WGLC this = document, surely you might as well = make
this
a = working group = draft.

If it is AD sponsored, then the = first question is sufficient - = look
at = it
now, = and then it goes for a four week IETF last = call.

Keith

-----Original = Message-----
From: = mmusic-bounces@ietf.org = <mailto:mmusic-bounces@ietf.org= >
<= blockquote type=3D"cite">
[mailto:mmusic-bounces@ietf.org] On = Behalf
Of = Miguel A. = Garcia
Sent: = 09 May 2011 = 08:04
=
To: = mmusic
Cc: = Flemming Andreasen; 'Yasubumi = CHIMURA'
Subject:= [MMUSIC] Process for = draft-salgueiro-mmusic-image-iana-
registration

In = relation with the registration of the SDP 'image' media type, we = are
going = to try to expedite this draft, since it is a very simple = missing
registration.

The = idea is to progress the draft as an individual = submission,
AD-sponsored draft. So, the chairs would like the working = group to = take
<= blockquote type=3D"cite">
a
closer = look at it (it is a short one), so that we can go to WGLC in = a
short = time = frame.

So = please, send comments as soon as possible. Do not wait to the = WGLC.
=

BR,
<= /blockquote>

Miguel
--
Miguel = A. = Garcia
+34-91-339-3608
Ericsson = Spain
=
_______________________________________________
mmusic = mailing = list
<= blockquote type=3D"cite">
mmusic@ietf.org <mailto:mmusic@ietf.org>
https://www.ietf.org= /mailman/listinfo/mmusic


--
Miguel A. = Garcia
+34-91-339-3608
Ericsson = Spain



_______________________________________________
mmusic mailing = list
mmusic@ietf.org
https://www.ietf.org= /mailman/listinfo/mmusic


--
Kevin P. = Fleming
Digium, Inc. | Director of Software Technologies
Jabber: = kfleming@digium.com | SIP: kpfleming@digium.com | Skype: = kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - = USA
Check us out at www.digium.com & www.asterisk.org
_________________= ______________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.or= g/mailman/listinfo/mmusic

= --Apple-Mail-35--681166214-- From yuepeiyu@huawei.com Tue May 24 01:02:51 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F719E070A for ; Tue, 24 May 2011 01:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.456 X-Spam-Level: X-Spam-Status: No, score=-97.456 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_50=0.001, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeuRrWuC3BRP for ; Tue, 24 May 2011 01:02:50 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C162EE06E9 for ; Tue, 24 May 2011 01:02:49 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLO00IBAX0LPO@szxga05-in.huawei.com> for mmusic@ietf.org; Tue, 24 May 2011 16:02:48 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLO00E8FWZREM@szxga05-in.huawei.com> for mmusic@ietf.org; Tue, 24 May 2011 16:02:45 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 24 May 2011 16:02:32 +0800 Received: from SZXEML503-MBX.china.huawei.com ([169.254.7.71]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Tue, 24 May 2011 16:02:33 +0800 Date: Tue, 24 May 2011 08:02:33 +0000 From: "Roy Yue(PeiYu)" X-Originating-IP: [10.138.73.89] To: "mmusic@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_uJPPkVdntYl2B+50A/ndpA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Review Report of RTSP 2.0 draft Thread-index: AcwZ6O+T9jCll7vaQYC1JLTWCU/oVQ== X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-Mailman-Approved-At: Tue, 24 May 2011 01:43:40 -0700 Cc: Flemming Andreasen Subject: [MMUSIC] Review Report of RTSP 2.0 draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 08:02:51 -0000 --Boundary_(ID_uJPPkVdntYl2B+50A/ndpA) Content-type: multipart/related; type="multipart/alternative"; boundary="Boundary_(ID_oSmK99pLoF9tlM8GlNoVFw)" --Boundary_(ID_oSmK99pLoF9tlM8GlNoVFw) Content-type: multipart/alternative; boundary="Boundary_(ID_oyFVgzfTuoc6nZU5FiAL4w)" --Boundary_(ID_oyFVgzfTuoc6nZU5FiAL4w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGVsbG8gTWlndWVsLCBGbGVtbWluZywgZXQgYWwsDQoNCkFzIHByb21pc2VkIGR1cmluZyBJRVRG ICM4MCwgSSBoYXZlIGZpbmlzaGVkIHJldmlld2luZyB0aGUgd2hvbGUgUlRTUCAyLjAgZHJhZnQg KGkuZS4gZHJhZnQtaWV0Zi1tbXVzaWMtcmZjMjMyNmJpcy0yNykuDQpFbmNsb3NlZCBpcyB0aGUg Y29tbWVudCBhbmQgZWRpdG9yaWFsIHByb3Bvc2FsIEkgaGF2ZSwgaW4gYSBzaW1wbGUgZXhjZWwg c2hlZXQuDQpQUzogc2hvdWxkIEkgcHV0IGl0IGluIGFueSBzcGVjaWZpYyBmb3JtYXQgaW5zdGVh ZD8NCg0KQW1vbmcgdGhlIGNvbW1lbnRzLCB0eXBvcywgYnVncywgdGhlIGZpcnN0IDE0IGNvbW1l bnRzIGFyZSBtb3JlIHNpZ25pZmljYW50LCB3aGlsZSBvdGhlcnMgYXJlIG1vcmUgb2J2aW91cy4N Cg0KQmVzdCByZWdhcmRzLA0KUm95KMDWxeDT8SkNCkh1YXdlaSBTb2Z0d2FyZSBUZWNobm9sb2dp ZXMgQ28uLCBMdGQgW2h1YXdlaV9sb2dvXQ0KDQpONSwgTk8uIDEwMSwgSHVhd2VpIEJhc2UNClJ1 YW5qaWFuIEF2LCBZdUh1YSBEaXN0DQpOYW5qaW5nLCAyMTAwMTIsIFAuUi5DDQpUZWw6ICs4Ni0y NS01NjYyMjA1OA0KRmF4OiArODYtMjUtNTY2MjQwODENCk1vYmlsZTogKzg2LTEzODA5MDMwNDAx DQpFbWFpbDogeXVlcGVpeXVAaHVhd2VpLmNvbQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQqxvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6KjrL32 z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+w0K1rnIzrrOxuTL+8jL0tTI zrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sahorvyyaK3oqOp sb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXnu7C78tPKvP7N qNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMg Y29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQppcyBp bnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxp c3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4g aW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRp YWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29u cyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElm IHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQo= --Boundary_(ID_oyFVgzfTuoc6nZU5FiAL4w) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hello Miguel, Flemming, et al,<= o:p>

 

As promised during IETF #80, I = have finished reviewing the whole RTSP 2.0 draft (i.e. draft-ietf-mmusic-rf= c2326bis-27).

Enclosed is the comment and edi= torial proposal I have, in a simple excel sheet.

PS: should I put it in any spec= ific format instead?

 

Among the comments, typos, bugs= , the first 14 comments are more significant, while others are more obvious= .

 

Best regards,=

Roy(=C0=D6=C5=E0=D3=F1) Huawei Software Technologies Co., Ltd 3D"huawei_logo"


N5, NO. 101, Huawei Base
Ruanjian Av, YuHua Dist
Nanjing, 210012, P.R.C
Tel: +86-25-56622058
Fax: +86-25-56624081
Mobile: +86-13809030401
Email: yuepeiyu@huawei.com
http://www.huawei.com
---------------------------------------------------------------------------= ----------------------------------------------------------
=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE= =AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2= =CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB= =F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attac= hments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!<= /o:p>

--Boundary_(ID_oyFVgzfTuoc6nZU5FiAL4w)-- --Boundary_(ID_oSmK99pLoF9tlM8GlNoVFw) Content-id: Content-type: image/jpeg; name=image001.jpg Content-transfer-encoding: base64 Content-disposition: inline; filename=image001.jpg; size=6737; creation-date="Tue, 24 May 2011 08:02:33 GMT"; modification-date="Tue, 24 May 2011 08:02:33 GMT" Content-description: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_oSmK99pLoF9tlM8GlNoVFw)-- --Boundary_(ID_uJPPkVdntYl2B+50A/ndpA) Content-type: application/x-zip-compressed; name="Review of RTSP 2.0 from Roy YUE.zip" Content-transfer-encoding: base64 Content-disposition: attachment; filename="Review of RTSP 2.0 from Roy YUE.zip"; size=26542; creation-date="Tue, 24 May 2011 07:29:41 GMT"; modification-date="Tue, 24 May 2011 07:29:41 GMT" Content-description: Review of RTSP 2.0 from Roy YUE.zip UEsDBBQAAAAIACF5uD4/d78QBGcAAFlyAAAkAAAAUmV2aWV3IG9mIFJUU1AgMi4wIGZyb20gUm95 IFlVRS54bHN47f1jsC3B1iaMLtu2bdu2sZdt27aNvWzbtm17L9vG3ed9+/Y5ffp0xPfvi3ujn4pZ UTWrxqhZmc/IkVk1cg4FaWAQFAAwAAgAAABCgOSdxM4gQACAAFAAAGSAOUAtYTtbZxNbZz0VD3sT Jx06dxtrgoIpQIo8ACCA/4v/v0CVyqTtAANCl/o5v0iP2tCcsKoqCc47R4vEHDzDsxAN0uY9Hcp3 T2ZRXkuBomIbyYSRmamZGW/OZQXTupDIhQ6Z2JkCyV4T+0o10x2fH+ZWFIgkZ6HUDQGylwDjeG3t yIMPgEzbhgEZVMEtAek5EFVIOfze6+TCqBQi/0gKjFTtMtThlb07ebMbSCyYilG49yeIdDMlpcfO 3YXa+ABXAk/Lz7LKbwXCZDVqw3zHiyn6xAA9umqwP08lhqcowiAmdQB5FTLCTVMYZgJDMfnxb68x mbErAkyqCbqqwzCO6lIHcHndsUrX+WnhYJclYm+ZCBZ6QM8l7+t20J76fAZ2wUizVldW/pTqbMx9 A2CX+qfPNZtJ8Pir0Deraa7FcsKalBdwHfIh/sQsMXx5h31PaAAuBbDpgvoS4cb7pxrkrTsEbxXs PtAP8o5yfjbejcwUmVo/qK+/J4l9VwF+gaNRBf5GrL06P+i8w+2UHmWE2BDn8EMJCymvlJcRYAM3 /4YEAPj5AQZQ+F9sEFm3xwT0rw3u/jUxaIAeQD1HE2snerp/rAkKOv6v7f3/LKoSZ+UGGWBGbiS6 hJM/zm0JgucWdMiKthGo4PWRXuI2RhQTBV+eQUhAUsQ6gUfXcvl/Pik3tzkeD2K8zdep2mccKccs 2aqrU7wp8dVflILDV/RnU5N5FOM7D94tP2R4R1hQMlZAE7StFRoi5nkBQLbn/AmNxNlcqJ6BRx4f WTmWcFdAMnl6gX82hdGQ5R0YpN6D2hMKeNqbPNYzKyuWm8x8cMZGmKn9RyRW4jU4c9e8rRdZC0T0 lFUW6nyljgBOtVPrSLPIN7TlHl+aGRREghAFG0s9cuSHcebeHfOOwksic51H8HbW3WqntnEmr/wa To3CeWiCH4rfxALHW2n4AP4T1wP4ktMe/251/KU0FgAEoLs1/X/T3c3O0crQzs7qHx7nf1Af5B/U B/x/uQ7/X8dfEkkNMSCM3ATeIBzbLtYQEWVeiwZ3W/r4x8tkNtggMf3J7enOL9gMMel+RHo1HXv5 Yvp9dW2FMwROdh6kroBKCvFItrbjBrWTcZIJjjC0ocULEgdFRrK2vKq+iY7DciJ9+C5B1OmutJf+ pzDZGCc2IxJh/kQOe6GMc3JpvGxa0I2C3cSDfnEB+BxZvr4VamFnJ9C8JD3p5wXOZhPbG+rYR2TW jIjkjuUQPFysFE6jP46OiXjs4S6T9Q9nHGjcWWPyg4aOYdmK8SvMmQBcQhyOH2mi0wnR1HYGw6Gz 0McEZe3mvVbq0e74WFJMZS/gf+KMiAfGp8LfI6R/OQP/95u/nPlXtkQn/Jc/E31JeYdPfRkmBNJE gFRaVjNRJkwZ2GgmHxqIG3OF+PQhFzszWk0xq7n60746ubxu7giEn9wIihvHJNUHRZ7Ci/Jo9OH4 IiAZviVVkx0SqEswp+rh1XiZxe/L5UYCUZef5xI9HVhPYMnAE60NjOZGdQIbt/YODB0DTicMixBj 6pE6nb4/sUBtsP8zaK9aDMLDOY9Vdwd1l+cxdCdcnSEwaVLMclkTC2GXwW5rf91YIvKAkFscSQDN 1b/icit+a/OwRrV9I9eIaXLUOh5DLhGzx66b3damr5QsUeZe+QcNFv4mP0f+nmf7anCd8nQAvsRu 3KO2yllHkPF8UmG2/iyxR51pZey3kUDQM9S5gjjKaKPkyuywb79y3quEZoSs7e5HvMNQUfU8wopv ft2tFadc8H7GnmZet68k+MOZD58seSg+XS/Afyr8bHXTjGXWv4XvDwiA8t+F72Ru4GhirOzsaGFr 5vSPGrj02XTclEi96iT+hMf05rARlUguy7RR+43aROLWPooeIpKbcR0RCxkOQhot6Q/qn6ohf+KD d4I/8+ez/3Mq4vcPh9XVFIggYjKlP0keHOeWTgMEUMSUj87H8wP9bhjw0zQsMf3t7hLWU3eG45ft 3MPnBXszfbYbd60lVSRu7wkM0K6Pcmab4lXayoMZv7hi1a0Ov6dyZ8QfRSc39vOdNmHyCnDi1VHy LwIcLsZvTN0bscI5F8/5mIuRwf7r752du+u5u8+MczAjfl9lbnMWS8tLr964beSvzK/BL82LkzGr L5zWmWyrl5PttqeHUzCr8O5rj7L3APzeG4NhVlR5sV/p+FkgPR4JG7YXJzq+6j2zJmyFCYvDqr/E D0N3tzQvCpw8amyzJIbZ8y8qvjFqOZy/1jDLEpBHFJV1OhDdRLP3v2rBdJ0H41qXxVtPOM+XcN3d N0T2yx0wYFpQnyF+lK9f1p6Ibyaw3e9EYINyuBV42c9Dd1I2ldWvCdqqKz/tkA2Frz0I2+/o6A52 nT71HsPej2Hq5GFtpdgxQPKhamt3lnb2Z/G+b1f3ubuCe679vh92fz56v4N6L7mF7Rjme3nj6Xc5 DA4zLrDAwz6zs9or6bE8fRHu0zrvjbO0MIYA8dqXCgwR4OEkUt8Gny5PNOSfW6qDwFI992WzA0nH Ao7z8RHFLU4Yei0cTn1cJI0xWT7zTI6J9TodBsYfKqk7ylQXbn0MQ8Fz5O1buNh1iwoSNp/edVcj KGGqKaKSTyqfIQp6TnzUS8/J2lQRZixx2hM6eHjVfxzvrg9vT19fbxCW8yUkJeTDZaUGEO1IuTOs DNzzQZnsXaBz+G8SyxM8wbg5emtguLaSzTlL2UImZGIbGwaO6LaPTCM/zOEz87MEL0P5XA+xX/sg dTTJ97IBWc5SkPuBAOA9elpixuT3iMKZbBCmLnXHD1eqCdoj7p4pxmSlJRGdnoKN1OkutFmhiOKm wK10BFVeKAKSTgJUpNkBa8mkaU8EN7xTIp1wHC7GAtBj/a4qsNsobct0tTt0FN1i/rz3V9Jq7w1R YcWJAfIAo7bXfe6TP3b57sKWrxjaQaALcfPIPkXwwyy99f0ug+OXtHX7xb+xoZaGP8ttdg/JE7VP IeXn21aMG1FJgRFtFB7Hvcu/w7QjbAvZIuBS8cIYrI5Spojh/SDQN6EobMZy8K3dfld98X5e4EQH zTRZMjpYzdwgVMsaWOfEOl+bvqfePFBM4ahM5bz3hunqMT6gN2NfbqPJ/6cFCmqu7akfdLZjd3vf fO+J/Hwlyk7FG9vfOkzYfC//9QEEUeD+Tw46BHAiaKChsXbH7XDUD2UG/0hiRNQoY28ZDLXrV1Mz ACKFAPVbsaNVr6+K3dhIlaYtVQrbUibVoAjFb7KNufJ6qHdnwrSCGNmIk1npmlIWzRA7Xpg9UxFG hBUDkCtaOkycGI65CY+9eSHAuTOFgxgwuioo2od3OrpCpNXjir0kZO3UlsZpM+L6UPuknM2wESn/ KcyJyCbrlKc+w3tQhLm4hUnkMIrTwTjQ8+MXsDb4T3xBQ8DegWvHmlrhl41+KAtlADVaqs9Gzi4b PKgqIQTd9JkGThVwwynvOD8lXZmkjiibmO0dNmtC+Jqwrs51piq7QPY9N+O4H5TyOdBA3OELQHf1 7nMpxo2oIfkdTUudYsatwEY6gler2DoB2t7LOC1We+y3sjlZuIvaC3BRtfn2AG6RGkRxIPGiYNxw J4EWZKLDm6pOhmCvpRAc/81l7LCDMEx2qC13WIDhcEqJJn0c123T7+LtqI0qy/EHZ60GtSO8GXqq wYWNeLZptBHt4lyDROMqpy+Z3YVzy9RDx4dnw4bOuUjD9tWdubsmXRpRGmwOkKieLm1LwcyNnEhq Mk1SdFsWKO++uZSNton55UopG/nhM0sIYkxIDERhL4UprKMsMOay+VqdXdhuusdmbcvagBlxBIWr 3o3dNHsCv7n9Pg7nT4i1cvMvauPMvWd699IEZkwQuOjznnSo41At0G1/1PH9CcmeJ3oKLZOoxVcG jcbv4paqlV+xnau9eaBeL/B98g7QPWUfuPVRAdJqokV99nzuHkLgAJ2Zh/LFhrX+0M5SCEJ4pSeh 1eowbtWmFssLed153KbP60qeVl/JOihJejRx3EuAdT0JQRzSGtwZDQKu/jcRKBpVooCAf/ij9x/u Jk3A76hQPVb5gBQBKsiEonN2cQnWSnkVR48LL73tv6yCga3X6IXI8lCJIb5YEWy8vmHGY2X4itD7 ehNV1WvM0mg1fLvcFmWBo4438ntO4ECaBgnN92bsfamoflsrUeJpP++UtaAqZsQHy/D5oCkhLpxa 0Dh2CE8lNYkcWVgZsyFPpFPIoD11/AkAJliJsQvM8RSkei/z4yPVpiJ8V0ludahrDvnFa43Hrz+H Spnf15sgEaJwUUVBa/4yVL1ru6c1u5N0wOlhAhlKmmsHXQnDIj/2QXhpI+oJ3+cQjiM/rTzFwsA9 B/8Kpv0JndcuKEGAjh8Q02kbF93VjHZ4LF6rxlpi41B7gp7ST5LpaM7rV37kvzw5PrWNoHMc6oZm olQmUN7bbiCwTNIfr+eiBmn0hegBo70Mqg/NyjoqhBRmaxkHxUkieTzGeC8m42zwPpn25POZIS/5 W29cXXcVW4t/HLJ2bUCJ2ru/mMJeGSZ/2t9SvDTpj6zy0CKdkIiJOqHxJvA4nWmDQnP0j6WiCfV6 R7n3OL2g1g2CLm7YtdylNrF1sEJ0DZCSRO+dUVF2IVNEX1JwI2JJiWrcqb2en3TiHOZzBTXoBfrr 0iPbJ1zQJMAG7xabBuvU+yBYERnP/E1SdlUcfHphKX/PEqVfm+r7B7gx70C1nncSsvtJYGEQ7YVS eD+OBTddGkasVjYJubwo4Nin5+UTzl2ct4u0DlAQnOI5xa1iSTCtvwkf67g7o1RKnruxG+la4HZg Eo2BG4CXBFy4bSDjlCf+ymnMYBs2MxRJ4O6acj9HKhADlrsYMOE0AFvOVl/wnLq9tGJUHsCPPGMO s/5SNifMXNIZuOLmOvWVI4lzuDcd5PLul1BAde+o7Jc4R6JHsaJorWso2klalgFfmkmtKVPk3Pln w+T2mRpa5jR9g5CXFm1M1TCywoy+mIqaF/iiknN5iu3Eeai0sQDvSyf6cPLxWbPSwewndifcrKQ+ qiIS2D5zhwXUbxWksIzdt0RRQancmdrqDaS8w2xmELfaJ8UEWlqotVFalTDt7/e3yTBlyd37T0aC Z5AG68urfjRmCJ4oI7JzCHzi+UryfAIMU4l3GIPN0Z0+ErUDNwjUgDQPbJsmT4HL0pd+cRaTabpO QlmZdulnJ1ZXySnEN5F8JH9125j4p8sYXoLqKtOQrH3gAodW6Ndgw5Ibd2AOYrSU3wkU7dEvw2jG oC9OOWqTJnXWs9saMyi/ehHXpJS/PndMwmdkKZfQFVWVpDQvjieAxoQ34QVICLtOIAai54KMc7Q5 gTlWIxADLdtuxuTW1X5ufj71OA9RJwPWVVUiohvW4X8NfhJNpiA/mh6vJvf7XaRBrnu14BigEhyN 7HBJPMwLOUkjDpYEOwARliAODa6qJsxBU7CBd2j4+/KD9jknZMwjAjyYKH+9VT3UnlxFPY82zqyH jLBrVENKJxRzqP/5VSe1Ydbn6uXyBDeSOS4OxBRlKnfZ6p8qpzQEW6jkyRfCdurK+gzGKCtPVMiC 5rLA/qexzx6AQG4NCGo7T78RLch21xBVkGIDhLZwhk6ebqeXN5PRQQMmoILIFDDdxHzUde8LEBnV K/DGilkVfWydi74/RaHAWLo1L7+IZjxqTonauabaZbJIFgQzyezB9d3FAmxQ+1j4dRuySIXhYDXv 3p+4MHVqiCLbDpDBeOO0LyNs5ylGMMLgLm7+qqD03YBBRfN3gT4PDA4LEHWDXVT1MeqlWXGwcAXy mNIFlWwQry3VFH1GwzBxFvua4LWbs1giBSgmsDgwY+EFJKvyeYbkJc7G3hnGSjU4nVupAZaOdEn2 HuA16DzrbSjezVlcmHq8jPltgK5j+LmA3GO3lT3bW4oc67VkJms8Goq+3BUttmCYn4tdIECX/I62 POfBMZsB5cpaMh/8uzRtKYucDunw4Ql2Exwxd95iQYBhkYh/vhb5fqJFeFrABgg/0NUBFuyEQELl ZONMmhM0sA2wMBZCtYOpn/z7SfZRAFlnDLpGrAwvNBQC47CTHYnBfE6wv2Ij9nq4zenz+pIotU0J J7bMxk4kFnb1fsvqIYKa559jyV7rVbt2lBZZSHAz36CKw7Ca2FNoidARwa86icKoNpfn7otYQxvM RkMMMvINMAHFAXfUaxGpwepkImVKbFKrPm1EKEZH13xNxbm4G0+WuiAVspCa+9UxVCb8ROn8++yd 3hhixTfNbTDgMs8S6vQZgOMzUEe4+AZsMHd4gVXzpDkXP8TICWguVUKNbRz1Zk7hy02oRaXyz5JB OuIm5kZdUub6PXfq5DudzgxlsT2BuSpXTdL27LMnpVPyt5sVoe74NvhXqhH0ZnLLrVtIKSQFxeCf of6ysp81qp5Tj0hajfX++1w9ZcWvxEp22xat5Jtw6Phnr22exqiRjAM/SE6pFb2O3/iZ3tyRRUcu AenmCTUf51cAigfyWhcNx6l6+5/jqTI2k+tM2I1VKwLvldYk7SQeR+TP1qlJoaNDRP7BBbPcSZwG kwQRi1KWRl+P3QiukRFhua292jmQ2hAf4UeCPV6VFDvVacX7oPSGVKYLzaktS2OEORSpyogKhLYR iL/yVqcMw+1duJU4Yw8Rp+mphAGtIyln+Zt+OpYCBbgn0xCqlYgxK38AQbJzhbUsDOCnsmcAkEya REWu52XKUpLLSUF4iM4hY/LMnpKe5SDOuEGwqs+hxKocBbreh3edQShrzeryXC14axnkieU7aFnJ B8vbbDvjvh0bJw0hfc8nVAA5+iH81ksMUFjR8oXjx4cpkCwOuK76Zajj83j2OsiSCcDbg+lETNEL wC0RdX0zCC/KIHJ6ITJYdNCyFwoxu6zIiCSGQRCGl+gQmRHYRE2tvjpqPhU/j2/Nwa3cv2UoP2b/ dNuojuIXsw27kFZEfhRjlIf7octWecR//8rXSOPqxcVbvYpZ7Q4IIoQMViIKklCoSoIV1BHodCE4 rYnudSStg/qCLeUMyDKMXUUYaLE8H+Zf9P64QMML+Dn3+5J1A2EfggbInsf3vlPzlUAiEdTGK+hh svAPBRo8WFTJVq2EdH4WpLevAnomUFEx5vFweBE3T+zh9XF2rJFn+kEc98a5mfGaKq9jWn1erssG bkHOzolqGgKmWLrBoBznJxNyXfns90KB+kNTV7AxVmJ/gIE7Oox7kS9jTPM2UgeFmBRIIyDiluFM dEdxN16Fc7uXsl97FbopffDrGcO5qQp8JygrngzOvAQU1c29q1TX+xmwoPkqbdkM5cKCuGlaDNYW nhiExeuYq2M48iO/NjtewURkyDF0rWSr8gghvcG5cIFhIFSSrbW73V81hQsUaVvlA/ycXr995GKV XvVPmYf9knWXit/3GiLW9DA50YGCru4hHAMMsv0iSKsPy1UoqH8HZN4hjI+BEmAMtO+li0HS6RjK gJKnOaFIcIQ2MOhyChpeUk6CIPluAHhkLYYb8grMXV5U4+ILuhl5Ngj8eVYzvRz/zzNkyoCMSmci px6Rl7M8Btjz2X4G+XJUlxP4C2O7tyxjWgrX+pve6p18GsY4RxJ6uAZNFrcFXQ2xsH3rzdfdaN/2 FXjAUvTV9erLFK++25/Z8eIPL2Xca3ZT3w/QzNZFU0pn5WyjkcNDESzPG7bzD+ZVnfPPnJL7rpvs wSC/97nst1/KC+LHi1fdSvjziOZ+8KBLMYPH+4pON/GHLE5fkMyQn+7i7FuAsDsalW/ptIJ78wQn +m4ZqWMtKu8phz+1WQp8VkC1wAvs1y9J0HQmD3IZ46Flg4WhXK2QselqyIXxuLJeAgqCdsc1651P QTptySQwjQnv+Gtj6+qdZqVwmeKj/FvlI5dXl2LHm+UFQ1ymXjJkGrrOcjP5K7KdMnXpLihF0L9b ssYqIMT29oTdww8Sib6Uf9TUZSTlrfGVhfsjDynbXfcK6PBrhB0t3XH4L/sWBbZRt+C2SQ2xaTgW By7NewGY6dSejBfAe1utH6MrXw6ReIjS9B9EMvXWW7HEx5jmvwofLG4u3aE3owWoM5TElREtvIky Ls/EZBqnYgAHmPaH3kKJhMedcrvRBl1wjZNCp9guLFV5IViGgj3pso2q98HvebdsWTSERUl/KjPd GbQ2SXzuodjM/7bAJUXGwE7+sbpRFG1+0lSjD5O/X9f6j4DRqEGy8EABUU0mg4AC+BcXEOhokSuR u8crdAiMezA30SVUwSuQeVzLsn37qCCrFYY/xLKZCunHXlEwoF3r2pc05/mi6VyAuTNTnVYh70DV wuN7q3YXhRnA9HA+4CbCxVk67gQOR/rqHhjAiMt348mjgUAcyawMhC3C0v20qEZLJzl7sZ2GqenY RNjT5BdBSQZDVCtkYLELXykEEjF5ZPU3DPGgx0RHLgCPY1WvysDE2Di64L76dHOoJE5FJwAw9mdo L0isu1HecBUwrS3M5RnnO2ck0tHQXCJ9Fmh2+pWnv/Dy7lxExvZp9Ifqo7trFLlgbJYNDHSaQrRV eeAmExqQwGt2EMi6hQ2CoBBYdFy8xeoIMj0TpdQVfJsqOpcflMqG4lN2jjH9SI1YOdodaUK8yhx9 saVdm6joeM1oHfroVkj12OHR49Ps7WPPRx0X3nBwKOfbLyYERk4dl7hromvMOwu6XbwGY88p+IO8 mxcfvPUlFBeoE0YSWciWWPP7KP7kYfehFRDk6LqaXBeKWinmi7n+emWT/2uc12WNumMlMz0AzM62 A/retMubSNjgiSUXGXbDqmo/9xf8qz/vbhtn5ZFakghnwjcHqy1n/HSNFR3cob8Bmj+sSp3gABrz TTd7J40z/4zU51gH4X/r+gcanR7urIlryd8iXuJLapRXSi/lyf/Iyuve6+qfpqOrgD+BWYcj3g/q 06wTbW9mApgmYmIqmqtC1Av1zt8j5GGxYZICTJWofLyswxOr1EmFRAvSbx6gXmW9HXcuwKtSgcXf l1xlD9lJRX4kwjPULt3xYljFo8a+65T29CdvCIM8iHpxxTibiusujkvrQFuCSVRYoigpk1frUscL hJVUraFBlp4fwmO6h9eFw8b9AVfOkzBIV9nVAgTlX5pCmWMGJsByMWfjFNamFIZvX1/EIR/TgYUa fHjiMMrRCBKi2ZgYQtkWOvE5gANjmsg7YUonka1vQmjtneMFRtAbqV/cHFn39wn37tcVRwcYb2iw bUvmSjJ8bGUUdinAJjvA+DVxecAHobIvK/N5ShVuJCK8da0+xPi5U706aB8rkq1PPcdKw+RjixgZ yAXI6K8p8bZAHD8UXl+P80m4oxCwTfC6PdFNKI91EoBVOnCYpMdoEjQWXwHRk4OR/566TG1aI8XU q7Gqwvii69PuLk/VC02nTJeuMVXiRWZcFMZk6rULD8Y7ogIn5YBh7ZR7u9IGb3ulLdqvD0M3VNsy Nozy8bkGZNSyXeKtX0cPwShFvMVpdCqe8A5g0O3d+TjkBn/IjVsjI+sx/9BdKaP89pbAaYQJJsvm Na9bdjYCeFdkao3mu2npUP2edCo/oBdR/6BoV4PHWQTclKFnTswYsxhCcOt2yXy9pgHzEf/FEGj5 ZsLsMyi0uFINGjW7waey7t0mh8m6lorG2ciR5qvs7mQeE4xdmscZWTQ4kuCZcB3wM3/lEXtOoJd/ at7qBXceMRjl8FpIcFGB69hC9MLckCUdAMHYoimv26x8X0ECAhV+oZdQA5VuoVV/BRQIqFPOj7PR h8flohuH+LUytgCxEAnHHYIKk8QNppzPo8coAUVbYgmyfX+irgJ1Zuq0AgNkElcDQDjOIO4PFgFJ w3xtDO1YUGozFDR/Eit77w0EfUoEXSdWtc+dbNZsdm9tlL65OtEMkD/2scLg1yXPCJCKTjsBnJOQ N7Kj4WwICnEHIwIcdPHCmNm5RmfH0BG+2y/HvBhXs/W6ImrRMlkZwzkqgq8vOUJSqPB4bqtzyaF8 OL1GFsDpxB1I5AxRzSmRNbLm6Uiu6T+y9YcdN56xMD5cDElPpAqxT/a8s0ubv6zmkBatKqo2oWmT qYQ4bf9PduAttefp4y2c6LvXUHWrvQvnnOrKWIjPJceqVCj2PPlw1CTkOXvWzbj4Vd7OixsfF+Pz KsbxWHU0dKNxCwt1z9aEw4OyJ1jfKTvrXp3gr0wyB9Pcn+4mNYF074NwSWPbJGXI0A6KNajOPr4Y SJH31SUdBPBp3+rHPyeQLIMZayotsWmMA/XGV2F/NCyj7I2PipA/w12h4i20jB64ZFVpimp97Svv 4JUZC3ZyN96IcvncILzCDbW26uRgPi0GkSxH/E3snjNLJAxYD3ct6V1cM4luIjOvkcIpv+oeFq1a 6pT/2M8Zl/fMcDIvYRMTsKLkaZfmzB9nkOXLjjIUwLhodvUfsg2l/haJtT1GqiNbsrXiHrY0OEzb yw1d0zEpiFjB++N0GIV0BMQw6tLXawBZIkMurOekkbq1xDQMejVDsbO/qH+3fgvUs2ogyklDsP3I ozEh0bkkQBAC6OhF9dbinHMmhXbg2PBQOTHnXBxxl4K0p1TbQVl+YkzxRHXlfdTmsoxUZ9Mtqrhv uoD2KcZRvXQi4W6/XcuddgeCecs1vw0iUWNATMwKRADZ5HwoVeqE6Mgljm4gAx6e8yY332bQUqZR 9+wBRK8xwNOuCu9QuSLoXnmMxWI855LdYQRN1eRfrfChOZn2Ra6hUpCU6cwJGeli0hZqrPWG1A3s uYh+BR/8UXkR64ozQ1fPQbmfmXP1EUYG39YZR+N0k4k+Gd9tBwfdZ+wMQGNmJWqOHdzCVgL3aq5C 8llnSNtbAVuGUzvS/5nIhLJQ8khc0ZqmKe9RMm46xs4PLK2U268EG2XO7LeR5x58DR2dQ7w8G/ob 5rJMi89ib22UJlsraJWIGotfB3TsmgZggEaomnvhOGsNPniKg6T1QiwwdL3U6eIFWwsNJaS8dhFu X4jAg/yMIiCNaY/mK5bvE34C/4+pPhvSAoMsSKyPC93snQxlA6NT4BAAUXyVXJD0c69Dh97dOYWv wQP9SvOBLVKncLdcVU1CAzdVHemL/pvJ1YTSZyulxy2GQmAx5KmFWRp45s1JM9ABouS9AA0Ysj4a 4YZiMCJSfALYY/k24KIwiAFEEDJwUBLbNZ4SFqAIc3pw5YdP7WSfAn5ggiFBhn4GtvUV3X2O4nFo pqDEnhgUKRnM+RJiRP/uqylMXXDrURoOdc6lKs5ERO9s7vrPTgjjHDOS0PSz5tX8ZQbbbvzvnNeS OTXbwtLmYx2Pgs8jyp8wkMem35N2JYygUHcbi770vbst3RPRv6gIqg1A+hulGXRoC/iFiKSyQAwV gdW4CNUGxyQ/5J5RkzJ4J6z1V60YF4/ROORpTQoZVeE3ULlmgJqW3VXF7Vg4a7UjlVflJRdChwlc ZbBCa4IRGIKX79D25iDP6526bTx3CPVCf7HXlIESgzvEZEiODah35yCDGwgWoNrZR5CqxVpS277O kmgeccwVGGuVvU2NOufQotUWU93aoPzpj68mRBg904GEFdtkxVTHIUYmTijvsCBuVBPc1kl+9JhX ULpPGEwWvGvStGqteWjWnZx1SKRv+17mZxQOOPSeW9xupBO4/PiInw8Jz7YZuoBA8tIB6cmvZvzk bDxPduQIGAsXfohSF/BTAbicJFCkeBOpQdrmoOQL0GFUlp9ec6mIxgzJYyfbRGhuwCID6L3dMbjF HU8EDf4goqEViMdF9tlvy5j59u+TIb1HYRqt1IwJ6dD+nftlI+uzfK0xi5zJGz1t3fcnZ5F6xKI2 ygELTMR/mC8CS/FkD29ZUOX0rZFOE8B3mFyPi/w8mH/xWLD58cEM0TOqkLqq49N9hzOpUjGLFecM w0MuMxqpME/DLcBXdi4g9IQSg0PrXBnB6wuS7KrBfROkg4QR9MHnIytC9olDNnXfIqCZo6Vw7MNY PNClYjL6ElDcaRmgael7yYDpAocTI7sYGzGIMKGdFtfxzgjDqO9FwewJdeNWiOldHcChjnjDjr97 8anPc41In/P6zFtkx8wwoe9beFVUzVVWr4EY7AVuY3tZqXXcznaIFmnRFxHfgLGH/kabE/EVpQMc ljYbsVsskJZg3OAwD5OkUbVJIr4BRoqRAbkv2bloCmUXvU54iETvICKl0Jk2uX36U6v5Ny8ZD7cT H6jEAU51q8Pjwt4wfJE8pGGJ+XhYXQhaQ8lPl4pdoQOGIfZp/pOOYG37ang8DE/yoTZh6B1qv3Hy Xh8cXoFGpI1HAWrHELv+LyYSoi8gURHl4MZZhEu9cnghrb6ysvp1zfeQ47OaocvQyEUcIKMFdhti Mz3/jM1hstoLnlftlRlDl1hAMPwTU5TLm6vy2Z/kDDF9U8QiXyfKdfAXWCwO0CTWtMr5HRUVPqOZ cJjQX5HrBPCp9HAa+xjTv2XTHDtKLC/xcfBwe71T3i8DldMymXZsy1fXl3LwL69wbgqVN5SiqKzi GOcDBwEu2FZ7Gs6X5XA1MszilEju4fsbR6e7xZiwyypOWBrP4uLN4C/E6Vk3r0m9M6XvhqpdCe1N AaP9dYEKmnytKvhzXZZsvakRhHjPYxJTE8qZX1ELMTLOn59bcrDUk9+7aHUQMjvSCkfw3RyomYdP 2CvxZZkneKegFt7rFb6hWo8VXNlPZnpcfltNbeEP0VbhwjSmK2shbunnxuLqZBo7gYbtPMlOaZSf 4oZLP9LweMHWEfgjJ+pQxtvV/vZzONApXklDUDxoTMbRrnFPt7Up1ejz9MnMxUHz/7bvTSAkg3yw 7oTqrYnaYaRQM7CnO0OFDpdl7wc9YL86sv3jcak0K9kfzoEukSdeOy5kWLGcg0tqFemMEGmALw+u gb8KWEiPBpUWWsjVrUHuZ29q/Usii4bt7mb9eOLuCDn2BQGHnj7uMBUoKuJSF8ydqBFiO9L/ywzP tvKc+BSfrNsRGR2GSOx3NWUQCMn2SsQT3ElVIpBQGEVm9dA5FNirJXzLWq2fda2kq2ntaUQOPisv v38WFMKDZHd+dmnWsc/CnW3LTphNl112UQ76SuJZBZWysolv8eOhcEsoyS3wKhxYXT5ANQLJjREY mqm5AQXbomQX/yM4hdbAZ2fgfrK1Hq1HDHmJx6EMczWnFjcsmhF3DOuxYecwWKxKK4MkzE7EeELd cLh88lcZpVbBfjPH6/k7K7A/wRK6Bw4ZhGCEjM8meEkQ1+Jj3y63hjMk7iERb4lJUEuD5BTJ7yrr FFG19OeR9r3xMZXEEFseOJ9tNnJncYlxkzFWXn9hrj0JxQp6WMd3AwYShGJpjSNLHaCuabbAkklR eR9hI6tAO08Eq5UnUBX1La6UoMlm0mT09y21BmpI0P0erpaf4KTtVfbk7mQ1GWFQlVlKR1/o05y2 pwBJgy8HCC3YYdSWclr36BtJNWJ90xGlOr4gMrx7Qvd2welERSQwNSHgE8DeGBwud4nXj08NcHbJ kjDhApfegi9sJnJ3pxOo5TzvxNmajrGS8DsE8N+Dfv6Vd2FvSBeOzZE93kfuJ5CTE8HcDdvBZwjJ qgq2R+b5B3ehXm9d8SI0KqXPcGL+hXTysy4P0UVPXWSILNtzsi6JSA8uEWQ1hY4kTyS6eES6jgiK hB30KOu8g2X7BJ9JZQaHjwx52AY9B/7vOfN1iFjBhSHtRaTvTMB3p6fL/bvrtoCgNrxw+kFCZmnp esHWTr9bHC5WifTkMnpIle8xAP5kuL5ceLmVvty+cP9sTrGIwmzqttL9Wu3Akaa5jrjDb3b7IZ6g 6jvyo1QyyK+s4892k1FF5Eirt3a2ns9+xAQU54R0TPeQXVjMXb9leHvKJQRvzPsgxsyFBYVy738B 1KuhETyR2tU5RnbjsbwekzZ6ayfb/LSrfLmSV8HkAuTfDzEuqnx0ZY7YmSq7HR2kfma/SEJWeiLa oHTlzRP/A0ilCk0SogIaZDH78CuiGeAqspPJqrhQNYm3Pn3d9I1KDHNPZYxIHR5lWlfXE4LgO6Zd S2lfEiOlW0IRd1C3iMR7+3NLjnVlzUUQro3c5QIQOrd0L9FhmvzkjHBG2bZicpa+ejbf7eqNwW8M QYifszv9gUH/CM27NJD9HaVqvAdoxxJ8BNlLdOa6LUoCKhUmSUHdVDih/AVnIIxXkN4IEQyjOXjF Z5dnyT3TkCMThXPxHdAxADnv3Wi3j9QeFvAqY6seMBGSzIUtXb9UIZrhpLvIW97yN+NiZLWEycsA 4aKT52KzEK6f8O82Frack1sYXNAbl2lSluqqM2ZR9YZZTGFzVGRHr2C7f8SnbPuU6LVkB9mIJ2Xs tEEb6cihnFTLY2hFYy483iREMIJtk4dxKtPN2mFW4XXbzNfcfShx95Zb4rceFAcq+tN0SV2lH0mb 32H4z3xuSK0knz3JHqurk+4gzbqXk9pG4v7K2gfX9FFEVxsuviX6kcesrFgwKDBAPK8FhLaVhq+l MK1E6nMRDE8nMcwBBKvhlJlHSE31P3Zt5sAO45ePJnVyWl4utMHJq3BJviLEnpz3Xs/hX6BygFXW crHPFSveFOeMGQKa25GOBnUhIsMpJHxnYiQdN13euP29rO41mVTNW536Oc4mwCoi0M3SW0k6WZL/ oMq1VL85+XlQMWSSXpxZ74NJvZWcHRBLseDSfACWYVSEYHlwDN/mfO4FowXxYud7oibk3p61tWJn pTkN9WG2VVeDiUu7bmDr20yqnF30OWMI8GA1xbELTkjZHsum5VMV8+mI6z4ZHMbUdUx1pcGlmZJs DTbENk+AN6c9G9VhRJJlhbyYemuN7CasZRNNtTlC+sWXyLP/CuAchQDbooOX8JtFJGjUruOsEIzC qbDmBTTAIgF0m/FDiE8zHummDujThhJsO/m4FxjM0s4drHEeEvjgzunxajD7vJwW7kq5r18Ce8JC S34+S+o3WARj0KjJ2OjvPbvidUhKvKSEHOg0dleDMCDmF2wL/IXu2KSW+fs+tgsJocO+J0j83Dxs rN+PSzEd+aWZZHM7J2aSmerPKqLYy/KSKNtFKhMUfyQSh59QbYJBaxi1TjNgsTD84IMAD64UGUaq PlQ0IxlEa1q1aZwR1nNPmhNRnz0ciR6kJ+c4M5GBuXjB69OLV1QzvhikRx6saN/cx9UfoiY41hbY 7MuXbSIv40sblzylNmn7htRpdi/gRqYKGIgcfadJk7IT1h8uJvK6ZLOvOIt4HsMxUqVpq5qE5aw6 3lJSvZt+K/ojxTWfIwIozHdMJ299J8ysozbh6GoMuaowxOIapUZ4DF1WU7P3mBDR6w3LNJnsgPxY UOs0M4LLw0F2jdVBzD1J8XCuWWwgNZKlMn4O+SNrhCq2jHkthea1s2H+GFw2NheVj8Ekova+8zSm jmGgrhpbFSQadhF0tzN2BmBG7K6dRfuKKcHPKC3jLaIo62ao9pOoelKWN5wBGXvJpxI59pIkRZxG 6mPos3JrYfYwdB5TMX9dgpZESMW1jzh87S2jYaDRqQdjLoRzOhnzNFT7r8vkY7SQBFYdyMSXcbIL GHN9YW6ztLachIYU8fNvJdZpK3VTu8mlOv3i36FKHMFsxXJRZWYT26CvchD3Tn0nqxfCIeMaBAna w9IwsEAm+OLVigFZlHIcjE9C64RjzrjMPZl9vhsrb1QZxAtim/pTl4B8yG6wBc9Vwe/nqqB+xYm/ qH3eqSP3NfA0FlJp0tbdvJwkm1Pt+aobcTt5xDiK49X5vjqyXgyP82CTHs9fmussPR9+Iv6BgANH zF19Hi2GA6v97OzsZb4zd3LoOo6LonAA9SPUkGl0k//wW7nAP8ymcHWB0DEVTRbsMN4cLR0lIl7/ nCWQMJDiVHgAgPI3Zbiypt+MARZoyyLZkzYjMYNwgIHdSvaTe2A5GAf0dr0L2XzZqacaBvdcNXio wHs0TcmhpHVxUXdmulRyFeKxcmYAdHvz0uK6QkaYjNp2SigRNEsxXybWLwSA3SKyLk1hsAYYjcp8 5otgXxaVdjZ9xQxLzd+WPeM+fA6VruWoVZuFsfbmW0KP8LwRYSh7E20meQ6YV1EvBdm4YOoUvx/y FUucrozRUt1idAwRh0XaMa5ZE/oJ6Qtou0xXQyyIB5c8Ajr6vGm2bE6CzlQqOykvnHUhiBi8ymwZ reHlGbLXo6fjWgdwkHiD4XP6WLrVGdRBlYOEVJi6fJggUicRUxR86xTGUEwpUWrJ0fF3yvlMjYbd oaxRdHCsdQNb90FB2W4ibFJNsLufxkoOOceysG4hRXA2LjlfIVfys4vKpOudnCJ5E2lgGyklyoid pZvhL/llc7nVBe2EFndETYAw+uoPAnRpfwJqNPiyQPdZraVBlELs5ZV2QPOQ/TSvLWWWs+Fr/GIU k1d44rTVpEnJPIHV7pTwSFKbuoB0ywe0LD2wubov/b/j4pw9U+P12+Hk5FPY1ioFIMSqMEtLKsCg L/UaFWR3hbpz+dzKoBbj753DBK4gq7XO+JmXUQ5hLZPbeldx4XFEbrZfyU7L0Umu495PlI9tMu4z hyCtcaxtCIHgyTNNk1gQwpjEACFUhlXk4+FLZRIWO19hfqz3ooPdnXYGMIpEbe8ga9fxoyGRwnMB fzdW6yfkMYNVHiRA4RV8S94jWvOPAGHR256VYP/8arWFsmyF/2MQLIMceRkALD12Xfo02onRiEaU y4ehtzuXid1xO2ZhNqfvINyEJT0LjyfXhEwqGyTga4F8OEHLwUqkJRWANvR+KTHyM1lVr0Q6+Ikh fP/PsId4H5PiDaXKzXgly+wcnRztLj+vlqWCCaXDQ+RfuwfGxNFl1EreY6Uit2VuCF+mluBroMup WRL804OMvsgL7d6WcZX17PFYaMDbQX8gkhgw+TGEOwZhAQcNNWn2OJhtOuv2fxHx3Ll669iYCw2R HGpUPUHGZpZCR2cAYlkSUCaFNz+ui2Xz9k/5R3AI9drNXitITNSNlwtYpAXs1SgA8TI/k+RDQTll IOFLcnKfUDi6CqMhaFqtB1n4K4px3YCzC/LWf0UO74hj9TfGd8FaRFAS1USztsBf1LYGCzp1w/Cg 43JojX/QkFKwkXZT4TET+Wx5PUrbmHooqYcppOVNbg04AOI856xFQW5j5UEHrPl/KRiI5YOOikzZ wq73QZCbRUCEhVTw6rfI3HbowiDmVz6ZCcvOoVnzsnkNjwmyiMYwUIazgxGAcBrr56+bcZzfnhZ7 3u2IM3asLrrtKNliHLRERMnWi66NuVNRGtQznDb/YDmQFZ+4zq8v1kBvOWvAllscVxIRF4GrThAu +FjYFWsuBvchgh2CGQDxCgRKYz4tuQgFO7uPLkmjRzhouBfx0KbZtGOJU0wa0oJm2G0n1g3FHV4v skp0BeRfvFILlU9wh6Zu31lOstn2NL0TCmH0twwJMqziixUdVpyZzt7/7QM/wF/1RrZLkmxuRFjY BqsO1BB00SPaWUwKJogakPYukx1j4OfFZ6QJltTdgWPg+iXFvqBgciGNUuAKYNPYYqHQR9IaM0eI xDyJjEpHo6SqxxT+I5CatdbhX16FhjTGGFuGEosJ6Xb0sjNm3u3ZH6+mcSmTO5nT3a+XGjnNS9iZ PWfCCOzHuuU8gPp/y31gaVmP4OeOnaZsi/nsykSrnC/MRJNskcLSX01JYBOO+qHTvKKoYeO+3LVk 4P/qcpvaL22c7HoBpffjKPMwRX7OjEmb/hL72nvaz57+72eawdz3kBpyzNICqn0zXr34LKP7e7Kw 60jQMzOYL10EprN3G1MvVyUiims+jW4ba35hkKPTY19f0/OTI9/yBtEsrgJttfBwLy+6PTt21ma+ H+DwP6ENv/H5Po8qV0tteLZ5Pl9PGTze+XK8Xy177971j88wH0lzf6JYkfuEfQro9h61HpXQi6dK Yjy1gWAhNdGKWJ/EWL9z5ubOMYh4QTCaPOi7afoRYpqZhy4Db8zCV63+fqaDvjz/1BXAONx2yIS6 u0iEjt3g0DH0xSDFKZQGbpFaUgs3K7+o+VIzKtgnRtALJjyNIHkJ60LpY40URdN9iiolDhWDF1Fq h3XmtHCbHadWwSYpkXi12ngIaY5OoL6iVZN5oYJdBbYaAOyGniIqmqXRIccuzwS2fNdCXJivvy/A Yc5eyZhRz6Pj9sDz+mKLtV4nYaC7dk/TSpFPK1k8NSS3N1H2djgs8XBYXuPSN1MoiFPu89K6Xf6K KU7tKP+yIn6iVIkJraephFUm8FUQ7wO0Hfdt0L+vnqHCDrA3sISESs0wvIeXuKpNI8pnKufV0Keb DyGcJJOVNcNWjIzsClx6BrWFBWyoNYPa99LzUl8iIcMfFZcrAHQJRFx00MdXor01qoW+kVnE/6Tt 69F1BrajWEhFVsCk4V2HgeYlcJn4OE9NAwl3exh4UzXpg8lEEv6lqAZfFY2aIrYs5JVKckoH/S52 CRtSq7oxZV2cKxhSfGl7cXD5+DW8LgnumoB3v8JppZfl+32FXEVIQj0nANQGSYKoTUp5zMZi4F5B URefSMuAIRtsZJaHHG6ORgaLMgcYEfRFACFTKJtpVOqUznKLRPgMxg0redmlsHAniLASSqQfGM65 5WsxWntF44XYq89mkP0GYYiRySIJyQ6UBSfGf8ZaePlJTrijHbgB1XQv0GVt2HpeSCWS2y2laAvR ojFeMN8Y9G51xRuPJosfE8ii981IKtOanEcjPcLv90w5twySqDysICJbgn9BUxAw5O2SjHoExypp 1i4KKHQKl6C/tAgMRmoD2zdayN9oXVCNZZUf1yihSzyWgngYC+R+Km4eYuRL7CSkAWDYGVLIzacs VqudZ4OwdXyOa1wF1nSN5+P+B3z05XP9XINRz4rMfH93TQVHOy5I32CvSdtMD8DbSq6yKSJ7KWhO IQxJTcfcCnl8KbQz1MQflpgVwbQDEyRwtkt/aoDAxrrvvI8YEEAW1a/DHXX9jZEY/1S40CaAUKyC W6Jlj9Yk/xOPieVPB1KKZ7n4ElQGc7cJfd+L99BavYIyseATPfRqZbW0KQKFSo5t2OY9Eb7qgOCr Kmc33iWURRPd7jI80lVAdHelnXd1+RKl3qmZsr4JhDyVjib/Cau3TEmkiPNfpy6qqGQSU9fGZlwL 8E54LCbfD2MT2CZYHxr6eYxZb/wzl6unSNkjxAZYLmg/OQHovkIBMSDvL4OYJ7OS9SJQfF7OI/1c ny6BK1EEqqaoROp9IdSy0SCj0C0xR270fHKLG7n+pB/+8zbr93Pz8x6HFaywi+kp8Z3ggEhdRamI HyiwcZgxlGcXu+JFpmALRFYF6bRNKAeRttzjLGfJRgH4u7jURJCauYs+ZNMQyQ0ccKBh46z4Opgp w3wO5pXa6rS3PW7H01KVDzllh9i5V7YjD/MS5jFAGqbcVPjqVrkGQfkeMGuFLx/Y2K8hCKSS4lZW 0Ps6ue2eNnqUiNlKgqOPcSm92T9R4zbaeIg2MZ5+Tu3gFiCb4LK9GCNBjAlHXhPr3q+cJOdAppVg ZANPJLjtrkuRasQw0c95tw/dHKW3OAGmSJg7PSAoAnrsdvK8KNNA2hrCbIaNwlwm1wc/P9AjA1l2 RMiWdEO2QOXOTW49wBsPO6paXIKpnp0G23hZ62ClWARHVo69EAUP6jvhNQaVeHFpcVufcoTzXLJB qFuXJ4BB3P3+rTGOf0ZsoV0iRsU06tldJjLpG1wpa4FSXfpqOdQ8r5h448VUlrZ5p2GGrfmBvIN9 Bq4jjGh9AgWZGdyO/TyGqWbRpEFCxes3H79XWusYlXVFdFbVa+owrMHXnmdT5pZLOe/G3G/Th+YG 7Rh0PhU/QHJ23V7fcusJgML7cWketdL9+nTKOVw+GATebAxMa8m5x86gy2dUlptfeR2paOZnKnP4 0Cy0wgsajBkVWGFujlPXkvnS5jd8oEp0wJJSyspvha/T/Tszd9+C3fVpNB8RJiuH7WdF4CQ6mwL5 OEGsNaa/JBwfMQPrRLUTw22kSff7zpzZy16kVdwwAJSpIPrjm+m/+7A9JfyDbKSIx/gWiooTDAzG AMs8P/cmCuOTbttA0ZrCI3h70MkT97pIa7jirY7hzzMGnQMNqfLl1R8I6gJCnRa8FkqP6AAchJAp y14jklYnxntdGaygs5GcsefWD/1lisfITPIAMwkMvPR5PMetjMLGo7ZK3yaYa+mLb0W9C/WWzEhs JbhVkQ9pT40v5H42x0DxhvBgckmW7Oxx1jPAH/7YogxX/9AD/MdpYNw2TNL9f7eEAAEAiP85B8/J 3MTE2el/TOH8rx3G/zmBMziuP3KAAUX0Bfhb2N0raSUERliZnahN9QTY8H0DbDMt/gXly6sRx6Tv 6Mh+9ogt84OnHNsULoFmqQMo5NAI3bzu1muDtlewnuN8CwWSlifeYJGuJwNYTk4qYjT+Fyp0fYgi yRfGoO/Qen0sZHk83/G6ZIQHw/hbFPZcVYWlzb0eeBO9XPMNzaGPehAXr5LG92WsDz6PbWHvjMT9 bLAkZ7w+X4EE55jo1b2/oeCF23OOlQ8cSInN1OTD83+cpR1O/s4YDgYAoIL9j39K+K8ScDY3sTH5 7/V/3falhqwdtihGD/EdvpiXnQ25K5a4S8VaPbb5oli91tIfd96dbE9XM1ZmuXNsyzgJifBAT0Eh bQ6CPCXqAJE3VkrRYokv6C7mxs6diFUSSkSIMvgIt2ePXv7j7Lsj6heiULjw+ORR2lrX+nNCpA9v kT95R9tYj3RVXhJUOHEMfxgtPJiJuqkzb3qcMO3K4kVAAH1o2O0noVOk2KhQzwaZUtE9hAzd2Y+J BqDwRBUwIb0hvInVNMrVVqkQS+rDDHEANzP/MD5Ben7/kafv9Ty0Md3qhBEZkjoHzY3oOZbFQQrC lbXEIjRrGATh6qs6CshD5MeJ95oQhpEGpdfUXfbumjg+gtqRiEjXFNLKu/gtL5WGFE1GLVYCEdo+ p1m709WU/cAOUILmsG3bulh99AkD8MH3y9KF8r7qZcXqKtoM0LiX7v5aBXu5I4r+Vk9nrn3dthV7 WgV9csn/cvUdyLe7Q21X0+EWzPguBtS7u3v5rIrTHbjhtRnU+0bJqfr6AJbCmCWHJs9FwKs72QsO 06lFGUoP/NWTNWRWMR7Ww9UC0Qiv0qQdbb9T+xEgLwCGGouYVXoM4yN+BBcHFnRYE2CHoO12hO7N 0UByUmgBnUWR9uYLRFhy6q3b9/nqwkx+7sIsLu6an7fjZ3A+CFz8pbe1C2cAFwdcdEBdz+/+Ax2/ YDfH++183+zIXWPo535bfNbvuwkHApVl9XT4JM7P5/11uDBOz/ehDqSH9LYOAn8uXMI5CKfABy/A ZoSx5tiYYkaMEYLRhcIeokv6l5vqKYDdFAP1YHPERdcmUIY45u35Y02hFT+Ksqg0iR40MXjbJKeV k+K5v5WmWv9gkAVOMjT6IpEt/p8gpnVcHO78Kznk0wwNJa6em+AhRae4/V/7/kMihF+x8hCU9ddw xbF6buX0bYdGIdcKSyNNS6TAXM5IFnJNwsThk1VTphDNfzK3N8umNX4vbx72iQoJ6qsVfPozjMao 36nsl0UfAYhXnd5e/AoxkXo2G6A/6FASLAIe4DiPDU82YWEHXdOCeGeF+apguey0RmuXyD8tij5x mfJAbJ8mz0YQl8Rskf9TF+4jL0cgyrjxpwKmZ3Iban4WARyHHvbFRirLPncLwna+T9Eih+B9WuX0 l1Ch67udyB9+q5FoIfYWztsWzNYu2rWMCSnDk1/QuqEf6Gw7NjwxLxCH7wcjDy03PVedO349N3SV R4uumx5BITuVYeDc6JmUnJpcJHGURj6sRocdLE4NwdOGS0GismZy4ST8LKSE3rKZnUHQIGwsEvZP gKoG/EOQU2us8syQxhNc8RT7SDOupu3JrSODWTWX43X5szAt+BJVrm9jdLXnR5fm8Y2MWnL6M7m/ 81Sn95oG1OiLZfov2RHVFqWyNTWny0w1s4lp2TEN28yxaI53gilB+i+BdHWDmDvQYM2Qp8YkPrZt +zR+yaDMMIswDREnjkhsdmMUZkAqpVIfMwE4lpKIvWe5Ba5CLWRkXOnFu2YQoA4vp4VPFryoFySb 3PJIddjGpRBHRQ2PGzqv3WfEpISGeWc1dTHiWO1bJQssFeN9MkDvOY6pD5R8RQxbV3jjTZuapmuB sLaV1/nqMaydAUfEW2JPzpWEeqSUAEQ1k1T+SAFveeqCrcn4AdOqrRJifjPS9sXZmo+7y3irwrga iH7M8JVUJ8ujIn7ZO4eHWlM9MwbrlVKtMRcg2ZLLiM/B26eUdNvotk9z0nYcgKb2r7tMJSKUXqml mauNo9mec6z286AuAW9KubCPZG+jKN+fGEsxxvyYlZx+gdRAq4lzAfFpH0FFO3e38NCpjOVDkxI+ eQGBgS9yE2jtcaHpCiv1hzS80Y8FfNtZzdwzmMCW8jXLA5NQXIpToQRfCmoxrbsBNWp2uGmk0pgY M1Xk1chUbQg7CqwJvPSxdrd6UQSrsG+T2ACDufH8bJ00BYYG4DlGPh0/xnvfNLPeusnztaT3U7TC ZwaQPfjVGI7XWJ7BerS8oMHO0x8bqfFWQiGorUFlWKz35kOZbVnajGrWuRcnUIIrajdhoD0EUARI 4xf99H2Lh8yGSxp158O98j2qgfSympvGs8Uvo1/uBTgHNUUJY2RdFsiSTU90sOFmN602TL9nkW9r XzOaWU3LId8wc3Hjz2g7yNHmlDYqw3P3tFhJ68Am8OoW1LHMwDGRMRybVR/Ay3u7owN1w6p/KpcU SZK9akjqY/B+lMDlvVaLCHe8gf9H1407HCwCCQIA8PHXccH+jxnczh7WJv81dXvpr8vaYMDokd/w C/e2A0Yx/w2xzBfMYpFJliLZiXXgzzoai7MoONt51YZfvznTfblbteA7orsJWTQXD5Lqa2+OO/r8 0KXnq8f99SA6liVNZETVFpYxCnuIwIfId6QM74MFGzcTj0w95TMFQo6nmYiRDZ/DfzFqOT42HI1w 1IfE8zwnU34acjGShAnp4E1DNLAvS2AcjsozUY4tnqjPv5IkdNyCFVODbTgxn4cPUWNoRnSs7XFK c4bx+If6BIl5b1nkOo8fUUZCvP9eYOjRHgeJ++B49YW/1+9UERCOUmtjJ/U32yATWIZrcVLLNTNJ UjnhkdC5nHpjnfbKHO/XMZ59A9HE2Zqw8Cvr3gvKrTzL+Livp1qiL+EGCfjGOwIcPDjvjNQOq2XV 5RG4hC+07yzBJvTOkCZMvximFqivODifM8w7olqkBF8wOLlFXCpiMG+YjoTVePMfKDF5Ul02rex7 ZMP+sloNGT2zaf1A+6xHxesk0DveJVatiMx9zdRVMhmk2+6VTLFS2yrjn+AYXcXuTTzW2Mwr3Vq3 FT4bdrnNbLVWE5z8yLYRLP3p+ni+w0RnYrsWgZQWuzkzEgV9DslS5i+9CIjv2BAlouBQ+TsV+6m8 sxLmhR9PMhLCMXY8JeYkemuqtaZgvHSCZCy7Ngyq4lDgo2SH8ju1tvuGkKHSBwQVtTRnUACXSfXG q5x0Z1DnVp9GfaHtFWp/v4N69WV26KZ6m+5sAJdNW/LXL60aAQ/Vl+mKBdQ+fNtOIP+Ke1SatPrc 6criRGUdOnCUaCB8xBQVfFBPnq1rblyHtOWkRHCqMkiDS6E0rtwgF0xQ0n4i+1cenNBzWpQchc6z QsuNYCJOi43IcT6Y9/R5SnjIsEL6hEi5R0lPoLihHFd0wCVNDZ6oHNDrq5BLmkAoFCmJFSE5tYbl d7hYopalMBAffAWpvQpz2eQg03q934Fu/I+uN3LMO0iu0N+DPDjInCxpVFjPLVBw5C6tVlfHyVj6 yNt8vTLddQrSM+oRhYgafflDWQLaV/keYBf+90ij9PrgCUpV5ZrtlsU7w6jGEsLDBycWDWir16mi fgjbyaZu8bb3XebYX3ee8xYa3HhF5Tz4dDHfBLogratHRFVqrnuyFp+5xsqY1trYl99hadPBRep1 CmTbJ+gAHptWeCZ7P0sUrfj0RzIKgJMuMcAp/aGpSVijHWcd52XnLe+eNupq08RLwehx0fNqFslp PC/LCeUx+VgzKEetUveqZ5ens8J4He093x8PWmLyfzhN7EctrQyq35Zhfi3qVUF7Ox1V3mLwlZ0t +IUASb1I+p/IxKjR8zbZ9rKjh+7RjJfFPSpRNAaHrVy5vY80W/TQth2jLXs3Y38C/6c2A0sCK6/+ by9XShcAAON/6+7/s6OfnKVjh92eGHqDvvajf+pr4iJtKSmYFWTAju3lr6Nf34i/iiUeEVJPW1tF YjZTu0tUmVHlKUnp5Jgw/kqL9lYXafwU9vFH7/v53vvly96XP0cX33Tam7GTu4svhw9fr5dv6vuj d8RvfeZ6h/5jdfbjZPFi3+B5dN/nOU3+51Me3y9rpreXHxcujfv+9v2bwatDe4dva7eXnw9X9/nm YXFzPyWZvvRh8lvox+vb8+fble+Sf1SMfvblynB+u/cyrpb5+Xb/08w7q8ebkw8vdPFPa9rgRUh2 FvzsB3TMz9fZ6zPfx+PdQ0ITgLMbn7dH+teCN4bb9uX34uja0w8OPP/Ocu8N3ceuLy8PPh592CwL cGPn5NnVLpwe3df+228su9XGzr73zbNHL/N3dSZNBfKbeslT4x93Tl/+urc5a/Oeb/pn7G/Z7J1S 3afeUsRoB9/vP94vb7cmP1dv97ml+D+eHL4+HXMKqQ8u9rfunmRW7x/XRxiGLJ1e6z+03y+jdw9H ZwYtGa0sYy+T+LMoBIn4vd16cvQ/k4bEdG0O1DFpIMPvnj3bn+sr1BayP9mabj8CTudksTxTFG49 W9OZ/LzPchmLfqU77H+/h4KZ1WrdMvXPzmhDoMm5xGgw8Fv3e3fn+2ornCqy8PHbDOOx45sDEPLe EE13i5SZ84MEI1kYSkRpuP0oNe38dv/h5UAlJhdb8mHS/JXUY7hwybZiXoZpk7Yyph69IWoWI8ZY EF+EyLqpytRB/skCnszDAV4JenTKAirol+4ylaM9dOZQ1VwFKFc77AqXxFZXcQKz4dXCANOZjds3 xpYMEuGUSQNDKnpLZjJHPsHWri+1kt4w3YgxrBs1ycmC+2s5GRYsWZaF7CrfFYR403yKLG7QXkl9 bN1GhSWIz2FAAsdqqn3q+7dy1MWbodm3wDestYxfaV0TdDrWLFsqthhLwzSbbRuXWTmqUkYW7LsI JEEsa8klFvd8NxqjEnBUhuXvRtqZRDPkd+4gdgC+hhg4081Dh3TzhZzgrGnDzFTTeHKZX3qxrP3B JovyhnjHUBvw1gUGm2DWPJu/NCVCEmwmEJD8Alo2KmRgwZBxOFyqGLfAEktyh2BaQwP+nrm/wiCa I0uDfalAvJlsnd8RaDRMM5Anb763WD9iLgu8163YyZkHT2NF13zhFNoQsW9p4CnWQtk+UA+lfaE6 MZInp1JHh2O1Wha9Md0Z8p2UJgaCsbbGMPDKm/lLLH08wUZqJNTSJJjFS5olnYPQKiscaEOotDul k3PEDQFYtjUIdioqZjiIBWu4bADdEhjCcDEEcPTsq3h/Q3DGiyM8qwwZ/3FD6/eraysR5QoYGo9n fX1dvE4hhqq+sA9AHVu6tgAEbVGG1S+TDVfAymp5xx2LDLRoMMaFeFg0RN1omCOkY1+UQigTCnj/ hUv2fF9ZaeRZYvIKBbY5m1xjWUgDrKExJaH0LgwNqfQHxWiq5EMcyuXrRRAPzVR3Z25FcjGOxA8S 6hFSDFhDY4w0Bm96sVRER8O/CombhUdck1ZN45GJL6FrDFQxoowYxyMdgAfxh8YYbPWJujAwR1CL pinEUEcUEA+tZT/g0KFku4ritBIK/cC1e/Zi+c8n8WGP4rzfCh3eFU149lFm/0SgB0y7ppFny3us E+2VOdzN9A1Go/2qeE0drpnF42AYjm40N/WGnpyUpt8o0/GfpxA7pIctXj+uTx9ogBTnEdiMSbAC yJ/RJWGqgkI8FMfPXkxhkd1/kSeAI7JESUfK3bBCWJMRY1xoaqeexIr11N+uVilet6clqGKolluy qtpS+3XizyRhJNwZUtC/Gu0ab16IYaHLpbN4FEVo66c2KBLUlNC3xKUYgsFWu1NmI0jTQAYG/w9L Ixj+q7TLY7CxKSVSDBemmtJc/zq7bPVX+xWKTgfDqp9jz7AqYzh9zM4lAbH3+a2aY1RCqJ1rO3fU TyNW6TKrXKZyaFpD2SpZn4rAQ64sgNYmJEWBHjNVwayYJ9B9YN0rP7Wvps5nEwIc+Tmrt+2H2Z/Z FTR+cpssu1yuLky/56K7BxgN73NYdnZVxibBHDTPTGYJw9mKvsGRVWmtSBE+ef13sPr5sboB72HZ Tn9aMxTiDRknPU5lWodiMaZl266nrHTCr6wyJKVwObule9ecMazWdcAoeT4madD0KFZcA9V0rT3P /iVHl6FSNF1FDkVQZnJ5GG87Fc+5+NgECngi7KmuT5K4dq8kXK30SEUczAkeNGlJsfQxtqp+ghDU 0D8UJ0ETXe5nS9gurGEy+CIrXTYJI8rgXBV1OGIOIiWUMWntzJNa5X1lbypwrR3fAx8Qcir5ISg3 SRni84eKEuHrvWK2BJ49x6UwjNwLY7I53FHalEOPgtWTdWhgl5o65qhupTHvi5uLhtX7d/q340Y5 QxNUx4IW7i59WK8mxWTKd7GOE7bhwciqB7Dtu9guOlsoKOtzA5Ev48O0moxMTZwvNDbFZFapb/kL SugmbStZZav2Lopq/Sbr2tl0+rkv5eDT0A9ckQn707E0dmXqe1iD2vK07Xn721gv5H/rQ9928twz J6xPWgMr8xUoUh7XXHesQTEa5iZl2xMTCmVPVZpzQpntDy8SecXcAIVn4QAdQ7j5r/4RcvAMVjtJ hwUxRqYqDxK2liXshvNShsk88l+/NORUIPFwMLoVM0G3GVj99rTRrGTjyg+p2Wh3FrGHJRYrKTTe c1O0mipQfXfgD3i4FUHxl3bKgvWK2D7Y+hj6+d7aMG1djf0f9Gnsu7c0zx2hZ/HJK/QHzi9ipNLj 64NOwZBLBsjxMRsp4YwYmdI9GNCSohkqZbubYcAoqxvRI6grYbaOyqMt6W00itl1CUz/CmColf2l g30nQKFiNEtdB7JFADVo2k6Dc39I6+1Womp/yNqjGKl2eqygc0xnYHYfOT67w6ShVcrJyoFaJK0X 0ZmjtGo5kp6OrQvCl2/5MhbDBVbbsNc9H+f4UEq0qTxX39WyGz4VaarkmSqDBGV2q5cYmqphFjyf nEWhWrzo6hj1GHCu9xYRGrFs1wSkmWFXhYoG2cg8AeDggUMBFIOMeO4Sz9oBKWA94xyDQ48pMPYe BRvKhfN208Sf+in+yia1jgWlzAAQjVWl19fCtBbjpFHARrZwWFyKcdNsO9UhXe9h+d8bhkX5qx7q dXMpjtI6PFWvrojoaW2NHIqcU6RMrd0xU2xcUxddVxCOZ6WBU2JcraseCb+Mz2FnyTM3+/UnbJqh pbI0UE+3xFU+losqMAbw2MNjIpx0w4B03ssFGhP+bpKgcSVTKqhpmdcYkSz4H6lV6QblLGnNWQsT z4zDRi2X6jbIgmbg/pbQ05pv2YuE33Pt9HD3S9n1kK2dKekkptaJLt9W/GvTMsBDzWktXPtRL0FD YvLCWlt45Vj9toyRim9rDqLKQfkr0lxjlJ0B/cMji9s1tJd8PkpO/reirYLWLAbqNBZ4QTnlUnnr 4d9ymItHgOuXNSr6bJ0usC0TViIDFVZ/2/YWPYuUGTNz3nBbf4Ov10PiRhX/dmLgrBdQaJxI9F8z 7xMOqI8oxr/M5FTkjLzjKtktY9J8rHbUtjMTvypNk2fzzFmk5ME4yIsAddWpGFSNxDnvjq/8/1BX 3Ap9vhcdrznrM4fHmF7rq/kMy2MaMS6MVXt6Gv6mFl1zdXL60HygpVofNpi0L7jnKRPvckj1LFTa yn8i6PgNnG6hV29xN1ysGD2RbSWLDWTarDEyrw/FvCImp9IfRLqGrYr6juiLsNzXD/J6SEguRdoX sG9QAtzV3mBVLTwNFPXrhCWNBUdatVdSTl5V0R0VKBflad5lbeRBoZ4Pe0iMGJ3+UOVTJX5yQ7qb 2Fg5w7MzBOcQRY+DFWdaVoGzR/ZuQTsR1WmHj3TqMvBbzmyC7IZjfkT9UyV9PQHSaYeFxoniF8HU JpkqjlWNGclUfLPcUuXU1q9Dl7tOhIWtW7QPtI85Nlq+J+zhv21I1O69WgVdZ6RLTHMoQntzTT1W V+8OuYYoAto5AVsGhDSm3p1yBFOcqLLdA6Fp+ThEoXV5kOCEjQRXq6lLJPNYd4pTgaSak9EgdNRo FLgR8DhbpKyJEVwKZFHdTnmbfQJK6Hx7c3nuEnEXx+vOxOOHgb2VpjOz/elfe+ekpOqnmaR+4sqC NS3uYnrxWuno0RyMdCyQYnCgfVIrcftNCBeEgWGcjpabtSVybKDkWXQl101sGt8pFVBMPVFW+hgy z6FIbiijR43MSPMuCMPCuEL+14QZTOKHJZAr0YtpHIq7lFYls+mKb9M4/vZaGEiM7Y4AvC/Oon5h e2r3jv+R9cRrzJ8dNzmjbk4tOWEKTWvquIy0WpnX+jonGUmD8KRG/jpembQxtDklDPC+d0/KETc5 ddKn8Sl+XHjseByg1l49W6jsPzH+R9dppffvb9X/pcDH2Q6pjaZ7/oJBy/BU4np7ZhJP9+muuez+ +1okhUTvWOYge3MCBAohCMN8DswPeJ6cnl3SI4urafpgQnJL9ZzWCUk8CARWRW4Jkos8XiAzMspX EepvVVzRsmC8LY3Lml9PCJ3sb7yqRdKpGrt2HJ7rv7gUQDHtPJ1Xb03fnQ0SgKFhct2NS4vR5XZE JIjOZAaIklGnLHxyr7zxltKNUU6sh13qV8mNiSbHyIzN+SLcoGF2uTMW2FDi9qYgR3UW9DYmeALv Eu3WDHLphO3zwpCfB8OIOtmZCIVWmCIAR8FI75DTR5a4p9OIoXHGjRKpSzF2K18IwdiNt8UuV46J kRnnYRZ1C46o43mfH5IxuRUnaD25JgruqEgxqtqIc5KywaxHUI2dY0LY6aldH782mfzVmeW2cTpM Tt/6t9aI2Vd3RLZVLBmV7f+WQrZTiHpjGTILzcrOBKt5TSaN844FaEaMba3p2d9CqJ4b4Vyitlct VvIaPIJJ0z/HSyRo5CIcXFmUNkqwGtvaIRocejskHW3fahweIzq5+3W46bIqtqrjPjgRwcXY/71E zgnfQrkjh0ocBWs1tsqDmpmOoXGZlY6W+T4okZlojAxT8jjSaf/Xdva20oEy5BG6CPnD4YF1uzIy uJRypOyvZ/z1OkNw+VGdiIfbBxJQwkBPDP+c+erdRVrbHbW40xF3kNIxeVOd2CKpQzG6zBsJ61AO WZe5ULaMawXRWKlxLlVv0BVu2ZFpwKrjEs+bIxADx6pT6kaH05DKRjVfUogdwebDiuIja9rpCMqd wThdG/5BWU1MwM50Hlk9ALszwPxLyXMK5tSnNIzfzrrHhJt7G+9WHZEbpx1WSa18kJSVyhIG8d0s aL99r2BhwBjryuYi5HVtC+4laCx3xGgtKX7pH23wHEeKrdg+E811NFkuGybw5Bizant3G6/VJYDS P59Hljr+HTZC+5rU7qhV1JoKt64s4n6YJzRggx2KZB9ABpwnVY0/ABPp9hsWjWtpA+lGX0LNRGDz xhiq1Oh3cNAcVNJhFGZhPKg4OItmYwheJ3kn1Ve1a3pzL0SRT0K0s0UqhjAuccQPIkjVBHJE3GEG bDZ4ojol2hk2JJCZ32YT0eNaFKL1ArBEKoI2KqnMZ8l0Lqqhq57fhQQnqhrQXN9JGAVKjIooa/9E Jcitgt0QuTM2RMdz/h2FYIxzhirhcuxD25z1rQ9so5GfD/2ikbS1xjQghD0YZAokz+VSalS1FjM0 ZiN2qbdx3b9l7ddaE8xRo+xpOzD84zxz8LxBrgHb0gaE9pcaig+s8qRsccv6lZXyUTqUBc5NLpAh N7VtVyrEw3EgVQZ+10lVdXeqgYLRMGx8gS//dfKI4QnxjmHScrU5OKcoNtKSjUYKyajWs8/fm2uE j4Ilraj1oKpfR/7KfoF9YsoablFV7Uowk4qprqldCiM3Bmd+Ur0Ta2dhq/SChXZDIIaGO4n+K9BP zZo6IQiNN4HEkeuc4bRMFIYcPTIfJiLEJnMX6nyaVAUM8I+zg2LiuL2nlSN0yutU4LAudYoHmO5i wSjnDQD/jp3sIUxyjUFje8WYwhNAw4wG/7J+z9AYSWdbv3UvJWNy62jDQZYEMcyc8++pEuF841g4 C4b/+AHKp1Z/GY9XCTpr1LCXDzERwadK1nn7h3LmtWs1gqrNnb1MvmEkRBtzaOxgoOs9oxQpbdTS flmWM0qLcmypY+csUIY3+/hKRqV/RLNEvmFAzU5LFD8IA9O6a3mPWowWDbLwH5an8tfylBVHwJk6 CUrNBw2dCuTW4hN9ElnZ/jHSq3eSGmm/Y5U3afKoQuMmTxvu0Sm8co5pmSTvFclchsQG25Q2cnLf hw0VjKZxTThUFrcEkrZmK+jmyd04rxgzVLdqenU9Pzp7fe3kTojzRhXSW1KbD8sYiJDaRYsWxYar mu3A0uBE3BJ/Nc/F4ufrQtAzlasfvAW8Zdi6NeE5oiKnlQf1q8zk//x05PCL0Xvy7fXi8fFCfX1c PNs82A67Ha67PTslmV/t2M05tTpL+0Pss/YxefaExIeFR/DtXkjv3Jvzvljp7cjL4r3px/v58f35 9Pru+yKDj1d6EzVLqTj7iXr7avdO4vFJGfLQuhjCd837tYvso/AlkJurO2UB/+7IpVPyg9jbi0e3 u3O982wX9lA72qt8kgxV+pDAl43Xm/7N4MWdTX/ydSeU21SS+5M90uGHtxOrEkZzqlKqiBT8Pf42 mPBrxu8Lp5faN7cH6OfsB/Q/vhoYFuxfJwEHAIBhBwAg/+/HfPaOFrbOJo7KJs7O//h713/fZ6Qz tLC91JBP2hJD9euUG3YApXIYiJlEU7Wf6DBd7YzqR8lLYMnRMBVrKLqj20uOL97BVGU5p/yqd3Ni Aodqc5IqfgW4hd07IMb3J0YBz8trcwgCPvrUtWqivjGOEKYSPUgpWar96F6t1ft5f8pMFcm91fSK 0P0Gdnl+LI2rrZln9bxZzlYn0ixcPbX3wX20/4ISmzM/QY5dvOxpsWbQGf0iVck5sDy338aIJtfL H6zsbXv+1uL/mHbr9dHdsc6FtKoUoacM8WwqeR4trwUMadwdPVs///5B4OiSOozt8nnecznXu0qS xWYp8ndESp7nmwDCybRVAu/VUV3Nrxf0OmWWQDeZj1E+15gZayaLtU006hixl0himRGZYRU/ZKKM +lXStHomEpXuKajrL62rBnW+OSh6GSkSLGVCoyzoilY6vM0kcXBwKEc2CbruhvrUOj5hmIAWoNRC O+rUFABOjLqZEB9erYUbnXDIgEIjcjxyA7Xgak5SwHErh2YuwxPl/JtEgaxyNWgxhy/JgcIyt6qh rGQFp6b0rMQAN5oxS8tYkCcb1RKAm8J0ElD+I0ENLXFKocSRjrge5cXGy8+8JD/6wFkKudYNukUu eymUWKeEM1MuKmvqjtevUjiHg66pKxNkn1uaOifMVXsqSPQ6skBfOYd9gAKDNyIgNxWFSJqxnXCI 6CKKgMulLxtcwyA5SgSn8/Q3BHd6pM9bXo6HsK3oPOc+hUQ9laodMRwS55EBslLxmNOUKQoNVXUO QgJ5Nw3HeoVNpUvzQg2NqS1ORJeSjJxctlYzP8UQj3geYIqS6FjfLbeWbzdKptFkPc808/LYJQ68 V38BJlMTc/ueP02jAoYg4pz13TXNugdLLyIYvD6wICFzDmxMVX3xC66V8TvxpP5HC6PKPPD55rs9 PM1eSUg+jXIzhLmWjuwqr9484ygpSwc5RVUY0SSD2cbNtdaem0mqJqX2Hu5cM0wyVLagJ3h4u0F8 1jDMH9wwhZBsBwb00patoB1ALse5ZKeEMxPdsXaoUiwHZlg8koF5uK2Q5HBYESi7Dp9STHPzJ1hs gwBU1WP/AChg1CGny2YE3newWqF4EiIl2otTifl6GjXQlkrSO5Zso8pnQ5liux/9UyBTleQj37e+ ViU4tctxCyqnaMU+YRJQswH9XMv2I0PCRiKJQqDfAEnjZkpqjH5yyFbYhGLHVGLqsGfMiD1OJI0U UfVoR0RAeZWaamgRNKPpkp+ESm5k+NOgkROymy6izwgWxC+w/Si6Db1bq7SBBdr1cRJoITdE4a0v tu86JXq7Dx8V3dJmz1WiKXsNyVcquK4tabhcFYMr19fPaPFCKvJg18YK9G/uidDEfFznwxqxnyyo LqaVe4axHjhQrAK69LE2alEPVc7xRF44oBJRPHdmJhhvGiMKfEyLp0DPvAnVEvEB9QjhuAFjg73C u3w4sOuEMgQDIzB2rrFuL7Y4s8gVTHAx1fUb4S5qtWvTCivu6jlk76oeu0vXPj/KP4M+P7Sf7HKX 39jOOn+HLImz9jIXUfLRT8Pk5HzySDqcy0ZfJ5yKaqXz59ZjJ8I9awuTzXc/CSs9K49EzNiPwlKS B2iPz6JStD8honk6P+iuFrlWhlg5yIY8jCSzxdtU3eYQt9zwXpzl770H40nkkcqLxb8SrCg06C2Z VL/u3NR+wYrZdJpWBzkU9x9aFmpUNj8qEd/SZuVLdQ3Gs4jHUsWXC3F5QbuW57eLJNU6DXpMILB4 yEpktAdf8FtCKdo9c9d+YB1+9qTWmmbPPj6pPlhpPvzm6v0iuuoSOre933w/EtuDHVp6Mq3TseXY WG+F0JYCyaD0v3C7vQ7Z7TU+57QOkvEs0yTnMAF3FvoEDctdUHIBkrLwpFT0uiOPIR4U1/3cGmZk VjLbhyH/g/OS8D5jFoBH2SMwle4cvdjwGs23jj3JzCv+BCabqkfj1BGD3CudScEq0g04TqaRvi1z FS51vqgztetvG7m9b8SP8vq2Rgz0QQrkJwN+apYEzIsvgZMIXrE/eYKwAJyc2cYrwcYIlPaS/CU7 VlH5XAgNnYKzK7a/DrATnW+X74aPBP5sfcQYZ9pPnXq290rRKXVQ8dt9ruq45dwF7srSzwkNQaDw 1/t8IlrALDWQX+ifn8+B3y9+gk/8tTnNP5Hn9LX8m74b8T+wBX4/aWz8cXcvSA8K7GHsU8JOFpEP f0p9Vmd90OeLqSO7xmeWVo08p1RNzx5lO+K2+jS8I5n6tGJhzwmRSajAt37GaPzw249pTuzm2S4d WhYV4c5CK1bLbsuuntZF/XerWtSjAHp4NzNsOcBDvcQfnKfxvN+ea734t9863/7s/pytZLrZ+dmB Fr52838fWv0w+X0v+3n/Ua/F/5lp6fSZdr5E7U6dJ5r7j8ttu+Ae8H90tDLb64mCgAAAikAAAIgA EIDGdkYKjnb2TvRGdo4m/51k5/9mO/gHvBMVpQcZUEJ2QX+Ex70yjV3OhTYDJnJwINRQdoUcW1Ez WUjmbX92mrYtwQdHvWbH3Wa7SbSuVXG//F1UC51EkAOJ5goSUnaOT6u1h18oHHOsxi/EhGPh9uYa 2nomgg0K6m8NsYFX1PcKBBZiIZMKs19CDS6H4FDcJO1PCWyxKtvgi7cNB4fRd4FyEB2jUN3p2k/a gEdMSQqIlSIRLXpstoGL+hSCgK5wSyCH/XTh1dqj4D1NDlRS+NPrFhmvk2mHCWKvuyvFjDZbJDOf GYV8I/lXZmu/KhyKO7UgBUTJQJHR2uysE/YtEOHUnU5W90cyoQ4HCU/RPZUeHcAhxihA9IW3ku5z +PhSqFWc2aPHiUosJCkzFdlKc7fHGl908vLzY4N+SJWwkjx4OinHcYmhxRYg70AwHHP9Ag/Q/xPv vGlch3//JRXCX1oi/CvvDOzt/y/t/omsxH5LbEaE0JuQrsECr6pmyGKMaiEHJEeJiH6560jXFeqC lGAWjUseaXpelHcw3icbzTEjY1f00Yum0nMW5p/bi8XoobeWeg1oRswbKLbsQxrgUh+LrRJ9t4vK RXka6TLt8io3hTpcElc6eb5wk0dAIiwJTI02lTosxilO+Y5QsWLI8djkiVExwmKHQR9VTFh0XX7W vfjZ+0/iMNpA6nweWLtQa/us1tfekuJVXL0OvRsgQOk7ThCrJiHP4k9D58dx9XQdW9Zf/aMFBB2o p6Xm9uRO/aPlvyxMDARHGpTYAvbCAtvAlmFtymVklJo47AQL4zSYZllaMCfxVALhSvWrI8U4Sapq bCTe10KDFb/f3r5eamvpd30h5N4VLgYdLjjYzBw32BXst9YwYXBIcJBrYDUlWpeVRD/Bb51htphh 2oBnKsD69mcY9X4MO86yXwbYBdtxIe3mYxzizuiqvkKE1uQf2ijUmiMVFoCe3/MJaizi513JojTb YZM/cnpDbF9eBsHTFtdJShdrvfWQP29TjqgB/hOdxbtQq5/+blkD/iMG91+bURcnZzub/8vofyIr ftI26H9mRYmNQbSIhlEEGu+IavKaxAgMxm/A1VR52rVK5nvWmdma/808+HLjCdR4b9BUErgeKpAX 3bRtHgrVoz1jDi4YPuBs2CCmaq8IeH0xCv59Wa3MF0vlH8yQH7iKoRPhEK9eLLpWtFZU1KoblS7F r7/5UqhSncJeLTOUHE+b2opQLXaNDn7T5Rj7I+qqVuO6/9TQVqT1YPcK5Ik7WhOIbzPfZCMIJSJf JYg5Hht+dAmZgEv4KJHJzJ3FR2h/wRDSB5EtB/9FEiqSacTZ3orgk31kLE1pwHn0Wjt5N9uT8Uf1 8LvkHfr/yxZAIFqA/1N2u3/Hf8h19+8K/tfUXP+K4L8t6r8k6vp3wf81z9G/wh7sv8bZ/4esR/+u 599z3/wTRRD/Wyacfxf+99wt/wQh1H/O5PLvGv497P+foBD4fzQJ4N8V/nsU/T9BJfgfY+r/XcG/ RzP+E3/E/y228d9F/z2o6Z9Al/k/hzj9u5Z/f2byT3zr/T9+gvLvSv/X/uG/wswMAOB/6y3+u/j/ 6ub/FbsW/yL+P5z+v0v/r63qv6LG+l8v/j/bWAVpULB/HIb9u5j9veSW7T+k/j9QSwECFAAUAAAA CAAhebg+P3e/EARnAABZcgAAJAAAAAAAAAAAACAAAAAAAAAAUmV2aWV3IG9mIFJUU1AgMi4wIGZy b20gUm95IFlVRS54bHN4UEsFBgAAAAABAAEAUgAAAEZnAAAAAA== --Boundary_(ID_uJPPkVdntYl2B+50A/ndpA)-- From miguel.a.garcia@ericsson.com Tue May 24 02:04:35 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB33E070F for ; Tue, 24 May 2011 02:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9Oa6SOl-63r for ; Tue, 24 May 2011 02:04:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 782D4E06D0 for ; Tue, 24 May 2011 02:04:34 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-fd-4ddb74a08e45 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 19.16.09774.0A47BDD4; Tue, 24 May 2011 11:04:32 +0200 (CEST) Received: from [159.107.24.158] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 24 May 2011 11:04:29 +0200 Message-ID: <4DDB749C.9040300@ericsson.com> Date: Tue, 24 May 2011 11:04:28 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephan Wenger , "mmusic@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 09:04:35 -0000 I am following up this older e-mail. The liaison statement from MPEG is this one: https://datatracker.ietf.org/liaison/1042/ I believe there is no immediate action for MMUSIC, it is just for our information. /Miguel On 01/04/2011 12:46, Stephan Wenger wrote: > Hi all, > We have received a liaison statement from the MPEG meeting that took > place last week. No action is requested from us. > They have an initial draft for the profiles of their HTTP streaming > project known as "DASH", which is in DIS state. In short, my reading is > that they are currently considering one "simple" and one more complex > profile for each MPEG-2 TS and ISO file format based mux structure, for a > total of four profiles. The statement should appear on the IETF statement > tracker shortly, but if you need a copy urgently, please send me a > private email and I will forward. > Thanks, > Stephan > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From kpfleming@digium.com Tue May 24 08:58:31 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3448E0764 for ; Tue, 24 May 2011 08:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFQMS0L1kOkp for ; Tue, 24 May 2011 08:58:30 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7795EE0756 for ; Tue, 24 May 2011 08:58:29 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1QOu04-0003gj-GB; Tue, 24 May 2011 10:58:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 7CA70D82AC; Tue, 24 May 2011 10:58:28 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMo5Xg8XxM0p; Tue, 24 May 2011 10:58:27 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id A6A21D82A3; Tue, 24 May 2011 10:58:27 -0500 (CDT) Message-ID: <4DDBD5A3.5050305@digium.com> Date: Tue, 24 May 2011 10:58:27 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Gonzalo Salgueiro References: <4DC791E0.7010908@ericsson.com> <4DC8D232.8000501@ericsson.com> <646F70073B3B490EA5D77F7C2C70C15E@power.oki.co.jp> <4DD4C70D.3050901@ericsson.com> <9F97D3180DE140C59E3E8A93238D1858@power.oki.co.jp> <16927C3E-74B8-4862-924C-A23A2FAFC271@cisco.com> <4DDABAA2.2090108@digium.com> <2EAE4432-8B25-42B9-9536-3EF824611A4A@cisco.com> In-Reply-To: <2EAE4432-8B25-42B9-9536-3EF824611A4A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:58:31 -0000 On 05/23/2011 05:50 PM, Gonzalo Salgueiro wrote: > Kevin - > > Thanks for reviewing. See Inline... > > On May 23, 2011, at 3:50 PM, Kevin P. Fleming wrote: > >> On 05/20/2011 03:56 AM, Gonzalo Salgueiro wrote: >>> Yasu & Miguel - >>> >>> I also completely agree with Miguel's assessment that there is no value >>> in describing the packet format that is already well defined in T.38. >>> >>> I have submitted an -02 version capturing the comments from this >>> discussion. >>> >>> Please provide any feedback regarding the latest version of this draft. >> >> I don't think that the comment raised here is exactly accurate. >> >> The stipulation quoted is from the definition of the '' field of >> the Media Description ('m' line). This is in reference to 'media >> formats', and only applies when the '' field is 'udp'. For >> T.38, the '' field is 'udptl', not 'udp', so this stipulation >> does not apply. In addition, even if the field were 'udp', 'image' is >> a top-level content type, not a value for the '' field. An SDP >> description of a T.38 session would have an '' value of 't38', >> which is defined to be valid by the T.38 recommendation itself. > > You're right. In fact, as a result of knowing the T.38 protocol was > udptl, I was intentionally broad in my statements relating to not > providing packet formats for ANY of the valid T.38 transport protocols. > Since we are in agreement that this registration is not a candidate for > consideration of packet formats as requested in Section 5.14 of RFC4566, > do I completely remove the innocuous item (#7 in Section 3 of > draft-salgueiro-mmusic-image-iana-registration-03) stating that packet > formats are not provided in this draft because it is instead delegated > to T.38? Or is it viewed as useful statement that adds clarity and > should remain in the draft? > > I personally don't have a preference either way. I suggest removing it. Section 5.14 of RFC4566 only mandates that packet formats be documented for 'media types' (really 'media formats'), not top-level media content types, and only for media formats that operate over raw UDP. The packet format description for 'image' over 'udptl' using the 't38' media format is properly delegated to the document that defines the 'udptl' protocol, which is the T.38 recommendation itself, so it appears that this is all consistent. > >> >> Interestingly, IANA has 'udptl' listed in the SDP parameters registry >> for 'proto', with the Reference being T.38... but RFC 4566 states that >> protocol registrations must refer to RFCs that describe the protocol, >> not documents from other SDOs :-) >> > Yikes, that isn't good. In this case a pointer to T.38 is the right > thing IMO, so I think this is something that can easily be amended in > 4566bis. Copying Ali for awareness. Thanks. I have a number of editorial changes I'd like to propose; would you prefer those be sent in some sort of 'diff' form as an email? If so, it would probably be easiest if you sent me the XML source and I sent you back a diff to that, and then you can decide whether to accept the changes or not. > > Regards, > > Gonzalo > >>> >>> Regards, >>> >>> Gonzalo >>> >>> On May 20, 2011, at 12:51 AM, Yasubumi CHIMURA wrote: >>> >>>> Hi Miguel, >>>> >>>> Thank you for your support about Draft of "image" for T.38 SDP. >>>> I agree your opinion. >>>> >>>> Best Regards, >>>> >>>> Yasu Chimura >>>> -----Original Message----- >>>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>> Sent: Thursday, May 19, 2011 4:30 PM >>>> To: Yasubumi CHIMURA >>>> Cc: 'DRAGE, Keith (Keith)'; 'mmusic'; 'Flemming Andreasen'; 'Noriyuki >>>> SATO'; >>>> 'OKUMURA Shinji'; Gonzalo Salgueiro >>>> Subject: Re: [MMUSIC] Process for >>>> draft-salgueiro-mmusic-image-iana-registration >>>> >>>> Hi Yasu, >>>> >>>> My opinions, as an individual, below. >>>> >>>> On 18/05/2011 13:54, Yasubumi CHIMURA wrote: >>>>> Hi Miguel, >>>>> >>>>> I'm Chimura from OKI-J and CIAJ. >>>>> >>>>> I have one comment about >>>>> draft-salgueiro-mmusic-image-iana-registration. >>>>> >>>>> RFC4566 described the procedure following; >>>>> RFC4566 p24 >>>>> The media type registration SHOULD define the packet >>>>> format for use with UDP transport. >>>>> ... >>>>> For media using other transport protocols, the field is >>>>> protocol specific. Rules for interpretation of the sub- >>>>> field MUST be defined when registering new protocols (see Section >>>>> 8.2.2). >>>>> >>>>> Therefore, if it use without UDP transport in m=image, should be >>>>> describe >>>>> the packet format. >>>>> >>>>> And, if it use with UDP transport in m=image, should be describe the >>>>> definition of fmt and the attribution(a=) of SDP. >>>> >>>> I get the point, I belive. But I doubt we can just define a single >>>> packet >>>> format for sending any type of "image" media types. I guess we >>>> should say >>>> that T38 is one of the possible packet formats, and the full packet >>>> format description when using UDP transport is described in ITU-T T.38 >>>> recommendation. If in the future, there are additional formats of >>>> "image" >>>> with UDP, then a different specification should describe the packet >>>> format. >>>> >>>> Also, notice that T38 allows several transport protocols, including TCP, >>>> UDP, UDPTL, RTP. >>>> >>>> My suggestion is that the registration of the media type "image" >>>> delegates the packet format description over UDP to the media format >>>> description. Also, the draft should say that, when T38 is the media >>>> format, ITU-T T.38 contains the packet format description. >>>> >>>> BR, >>>> >>>> Miguel >>>>> >>>>> Best Regards, >>>>> >>>>> Yasu Chimura >>>>> -----Original Message----- >>>>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>>> Sent: Tuesday, May 10, 2011 2:51 PM >>>>> To: DRAGE, Keith (Keith) >>>>> Cc: mmusic; Flemming Andreasen; 'Yasubumi CHIMURA' >>>>> Subject: Re: [MMUSIC] Process for >>>>> draft-salgueiro-mmusic-image-iana-registration >>>>> >>>>> Hi Keith, >>>>> >>>>> An individual document will not go through an official WGLC, but I >>>>> guess >>>>> the working group can always get a closer look at it before the author >>>>> submitting it as an individual submission. >>>>> >>>>> /Miguel >>>>> >>>>> On 09/05/2011 17:50, DRAGE, Keith (Keith) wrote: >>>>>> If you are going to WGLC this document, surely you might as well make >>>> this >>>>> a working group draft. >>>>>> >>>>>> If it is AD sponsored, then the first question is sufficient - look >>>>>> at it >>>>> now, and then it goes for a four week IETF last call. >>>>>> >>>>>> Keith >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mmusic-bounces@ietf.org >>>>>>> >>>>>>> [mailto:mmusic-bounces@ietf.org] On Behalf >>>>>>> Of Miguel A. Garcia >>>>>>> Sent: 09 May 2011 08:04 >>>>>>> To: mmusic >>>>>>> Cc: Flemming Andreasen; 'Yasubumi CHIMURA' >>>>>>> Subject: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana- >>>>>>> registration >>>>>>> >>>>>>> In relation with the registration of the SDP 'image' media type, >>>>>>> we are >>>>>>> going to try to expedite this draft, since it is a very simple >>>>>>> missing >>>>>>> registration. >>>>>>> >>>>>>> The idea is to progress the draft as an individual submission, >>>>>>> AD-sponsored draft. So, the chairs would like the working group >>>>>>> to take >>>> a >>>>>>> closer look at it (it is a short one), so that we can go to WGLC in a >>>>>>> short time frame. >>>>>>> >>>>>>> So please, send comments as soon as possible. Do not wait to the >>>>>>> WGLC. >>>>>>> >>>>>>> BR, >>>>>>> >>>>>>> Miguel >>>>>>> -- >>>>>>> Miguel A. Garcia >>>>>>> +34-91-339-3608 >>>>>>> Ericsson Spain >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>>> -- >>>> Miguel A. Garcia >>>> +34-91-339-3608 >>>> Ericsson Spain >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> -- >> Kevin P. Fleming >> Digium, Inc. | Director of Software Technologies >> Jabber: kfleming@digium.com | SIP: >> kpfleming@digium.com | Skype: kpfleming >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> Check us out at www.digium.com & >> www.asterisk.org >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From gsalguei@cisco.com Tue May 24 11:29:38 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED18BE0765 for ; Tue, 24 May 2011 11:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkx+HumYQ6qy for ; Tue, 24 May 2011 11:29:32 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 68B97E076B for ; Tue, 24 May 2011 11:29:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4OITS4p026147; Tue, 24 May 2011 14:29:28 -0400 (EDT) Received: from rtp-gsalguei-8716.cisco.com (rtp-gsalguei-8716.cisco.com [10.116.61.55]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4OITQBJ014187; Tue, 24 May 2011 14:29:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-72--610432371 From: Gonzalo Salgueiro In-Reply-To: <4DDBD5A3.5050305@digium.com> Date: Tue, 24 May 2011 14:29:25 -0400 Message-Id: References: <4DC791E0.7010908@ericsson.com> <4DC8D232.8000501@ericsson.com> <646F70073B3B490EA5D77F7C2C70C15E@power.oki.co.jp> <4DD4C70D.3050901@ericsson.com> <9F97D3180DE140C59E3E8A93238D1858@power.oki.co.jp> <16927C3E-74B8-4862-924C-A23A2FAFC271@cisco.com> <4DDABAA2.2090108@digium.com> <2EAE4432-8B25-42B9-9536-3EF824611A4A@cisco.com> <4DDBD5A3.5050305@digium.com> To: "Kevin P. Fleming" X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 24 May 2011 23:46:30 -0700 Cc: mmusic Subject: Re: [MMUSIC] Process for draft-salgueiro-mmusic-image-iana-registration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 18:29:39 -0000 --Apple-Mail-72--610432371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 24, 2011, at 11:58 AM, Kevin P. Fleming wrote: > On 05/23/2011 05:50 PM, Gonzalo Salgueiro wrote: >> Kevin - >>=20 >> Thanks for reviewing. See Inline... >>=20 >> On May 23, 2011, at 3:50 PM, Kevin P. Fleming wrote: >>=20 >>> On 05/20/2011 03:56 AM, Gonzalo Salgueiro wrote: >>>> Yasu & Miguel - >>>>=20 >>>> I also completely agree with Miguel's assessment that there is no = value >>>> in describing the packet format that is already well defined in = T.38. >>>>=20 >>>> I have submitted an -02 version capturing the comments from this >>>> discussion. >>>>=20 >>>> Please provide any feedback regarding the latest version of this = draft. >>>=20 >>> I don't think that the comment raised here is exactly accurate. >>>=20 >>> The stipulation quoted is from the definition of the '' field = of >>> the Media Description ('m' line). This is in reference to 'media >>> formats', and only applies when the '' field is 'udp'. For >>> T.38, the '' field is 'udptl', not 'udp', so this stipulation >>> does not apply. In addition, even if the field were 'udp', 'image' = is >>> a top-level content type, not a value for the '' field. An SDP >>> description of a T.38 session would have an '' value of 't38', >>> which is defined to be valid by the T.38 recommendation itself. >>=20 >> You're right. In fact, as a result of knowing the T.38 protocol was >> udptl, I was intentionally broad in my statements relating to not >> providing packet formats for ANY of the valid T.38 transport = protocols. >> Since we are in agreement that this registration is not a candidate = for >> consideration of packet formats as requested in Section 5.14 of = RFC4566, >> do I completely remove the innocuous item (#7 in Section 3 of >> draft-salgueiro-mmusic-image-iana-registration-03) stating that = packet >> formats are not provided in this draft because it is instead = delegated >> to T.38? Or is it viewed as useful statement that adds clarity and >> should remain in the draft? >>=20 >> I personally don't have a preference either way. >=20 > I suggest removing it. Section 5.14 of RFC4566 only mandates that = packet formats be documented for 'media types' (really 'media formats'), = not top-level media content types, and only for media formats that = operate over raw UDP. >=20 OK. I can certainly live with removing it since we are in violent = agreement that it is not required to be there based on 5.14. > The packet format description for 'image' over 'udptl' using the 't38' = media format is properly delegated to the document that defines the = 'udptl' protocol, which is the T.38 recommendation itself, so it appears = that this is all consistent. >=20 >>=20 >>>=20 >>> Interestingly, IANA has 'udptl' listed in the SDP parameters = registry >>> for 'proto', with the Reference being T.38... but RFC 4566 states = that >>> protocol registrations must refer to RFCs that describe the = protocol, >>> not documents from other SDOs :-) >>>=20 >> Yikes, that isn't good. In this case a pointer to T.38 is the right >> thing IMO, so I think this is something that can easily be amended in >> 4566bis. Copying Ali for awareness. >=20 > Thanks. >=20 > I have a number of editorial changes I'd like to propose; would you = prefer those be sent in some sort of 'diff' form as an email? If so, it = would probably be easiest if you sent me the XML source and I sent you = back a diff to that, and then you can decide whether to accept the = changes or not. I have sent along the XML separately to you to do with it as you see = fit. Regards, Gonzalo >>=20 >> Regards, >>=20 >> Gonzalo >>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Gonzalo >>>>=20 >>>> On May 20, 2011, at 12:51 AM, Yasubumi CHIMURA wrote: >>>>=20 >>>>> Hi Miguel, >>>>>=20 >>>>> Thank you for your support about Draft of "image" for T.38 SDP. >>>>> I agree your opinion. >>>>>=20 >>>>> Best Regards, >>>>>=20 >>>>> Yasu Chimura >>>>> -----Original Message----- >>>>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>>> Sent: Thursday, May 19, 2011 4:30 PM >>>>> To: Yasubumi CHIMURA >>>>> Cc: 'DRAGE, Keith (Keith)'; 'mmusic'; 'Flemming Andreasen'; = 'Noriyuki >>>>> SATO'; >>>>> 'OKUMURA Shinji'; Gonzalo Salgueiro >>>>> Subject: Re: [MMUSIC] Process for >>>>> draft-salgueiro-mmusic-image-iana-registration >>>>>=20 >>>>> Hi Yasu, >>>>>=20 >>>>> My opinions, as an individual, below. >>>>>=20 >>>>> On 18/05/2011 13:54, Yasubumi CHIMURA wrote: >>>>>> Hi Miguel, >>>>>>=20 >>>>>> I'm Chimura from OKI-J and CIAJ. >>>>>>=20 >>>>>> I have one comment about >>>>>> draft-salgueiro-mmusic-image-iana-registration. >>>>>>=20 >>>>>> RFC4566 described the procedure following; >>>>>> RFC4566 p24 >>>>>> The media type registration SHOULD define the packet >>>>>> format for use with UDP transport. >>>>>> ... >>>>>> For media using other transport protocols, the field is >>>>>> protocol specific. Rules for interpretation of the sub- >>>>>> field MUST be defined when registering new protocols (see Section >>>>>> 8.2.2). >>>>>>=20 >>>>>> Therefore, if it use without UDP transport in m=3Dimage, should = be >>>>>> describe >>>>>> the packet format. >>>>>>=20 >>>>>> And, if it use with UDP transport in m=3Dimage, should be = describe the >>>>>> definition of fmt and the attribution(a=3D) of SDP. >>>>>=20 >>>>> I get the point, I belive. But I doubt we can just define a single >>>>> packet >>>>> format for sending any type of "image" media types. I guess we >>>>> should say >>>>> that T38 is one of the possible packet formats, and the full = packet >>>>> format description when using UDP transport is described in ITU-T = T.38 >>>>> recommendation. If in the future, there are additional formats of >>>>> "image" >>>>> with UDP, then a different specification should describe the = packet >>>>> format. >>>>>=20 >>>>> Also, notice that T38 allows several transport protocols, = including TCP, >>>>> UDP, UDPTL, RTP. >>>>>=20 >>>>> My suggestion is that the registration of the media type "image" >>>>> delegates the packet format description over UDP to the media = format >>>>> description. Also, the draft should say that, when T38 is the = media >>>>> format, ITU-T T.38 contains the packet format description. >>>>>=20 >>>>> BR, >>>>>=20 >>>>> Miguel >>>>>>=20 >>>>>> Best Regards, >>>>>>=20 >>>>>> Yasu Chimura >>>>>> -----Original Message----- >>>>>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>>>> Sent: Tuesday, May 10, 2011 2:51 PM >>>>>> To: DRAGE, Keith (Keith) >>>>>> Cc: mmusic; Flemming Andreasen; 'Yasubumi CHIMURA' >>>>>> Subject: Re: [MMUSIC] Process for >>>>>> draft-salgueiro-mmusic-image-iana-registration >>>>>>=20 >>>>>> Hi Keith, >>>>>>=20 >>>>>> An individual document will not go through an official WGLC, but = I >>>>>> guess >>>>>> the working group can always get a closer look at it before the = author >>>>>> submitting it as an individual submission. >>>>>>=20 >>>>>> /Miguel >>>>>>=20 >>>>>> On 09/05/2011 17:50, DRAGE, Keith (Keith) wrote: >>>>>>> If you are going to WGLC this document, surely you might as well = make >>>>> this >>>>>> a working group draft. >>>>>>>=20 >>>>>>> If it is AD sponsored, then the first question is sufficient - = look >>>>>>> at it >>>>>> now, and then it goes for a four week IETF last call. >>>>>>>=20 >>>>>>> Keith >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: mmusic-bounces@ietf.org >>>>>>>> >>>>>>>> [mailto:mmusic-bounces@ietf.org] On Behalf >>>>>>>> Of Miguel A. Garcia >>>>>>>> Sent: 09 May 2011 08:04 >>>>>>>> To: mmusic >>>>>>>> Cc: Flemming Andreasen; 'Yasubumi CHIMURA' >>>>>>>> Subject: [MMUSIC] Process for = draft-salgueiro-mmusic-image-iana- >>>>>>>> registration >>>>>>>>=20 >>>>>>>> In relation with the registration of the SDP 'image' media = type, >>>>>>>> we are >>>>>>>> going to try to expedite this draft, since it is a very simple >>>>>>>> missing >>>>>>>> registration. >>>>>>>>=20 >>>>>>>> The idea is to progress the draft as an individual submission, >>>>>>>> AD-sponsored draft. So, the chairs would like the working group >>>>>>>> to take >>>>> a >>>>>>>> closer look at it (it is a short one), so that we can go to = WGLC in a >>>>>>>> short time frame. >>>>>>>>=20 >>>>>>>> So please, send comments as soon as possible. Do not wait to = the >>>>>>>> WGLC. >>>>>>>>=20 >>>>>>>> BR, >>>>>>>>=20 >>>>>>>> Miguel >>>>>>>> -- >>>>>>>> Miguel A. Garcia >>>>>>>> +34-91-339-3608 >>>>>>>> Ericsson Spain >>>>>>>> _______________________________________________ >>>>>>>> mmusic mailing list >>>>>>>> mmusic@ietf.org = >>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Miguel A. Garcia >>>>> +34-91-339-3608 >>>>> Ericsson Spain >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>>=20 >>> -- >>> Kevin P. Fleming >>> Digium, Inc. | Director of Software Technologies >>> Jabber: kfleming@digium.com | SIP: >>> kpfleming@digium.com | Skype: = kpfleming >>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >>> Check us out at www.digium.com & >>> www.asterisk.org >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 >=20 > --=20 > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: = kpfleming > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org --Apple-Mail-72--610432371 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 05/23/2011 05:50 PM, Gonzalo Salgueiro = wrote:
Kevin -

Thanks for = reviewing. See Inline...

On May 23, = 2011, at 3:50 PM, Kevin P. Fleming wrote:

On 05/20/2011 03:56 AM, Gonzalo Salgueiro = wrote:
Yasu & Miguel = -

I also = completely agree with Miguel's assessment that there is no = value
in = describing the packet format that is already well defined in = T.38.

I have = submitted an -02 version capturing the comments from = this
discussion.

Please = provide any feedback regarding the latest version of this = draft.

I don't think that the comment = raised here is exactly = accurate.

The stipulation quoted is from = the definition of the '<fmt>' field = of
the Media Description ('m' line). This is in reference to = 'media
formats', and only applies when the '<proto>' field = is 'udp'. For
T.38, the '<proto>' field = is 'udptl', not 'udp', so this = stipulation
does not apply. In addition, = even if the field were 'udp', 'image' = is
a top-level content type, not a value for the = '<fmt>' field. An SDP
description of a T.38 session = would have an '<fmt>' value of = 't38',
which is defined to be valid by the T.38 recommendation = itself.

You're right. = In fact, as a result of knowing the T.38 protocol = was
udptl, I was intentionally = broad in my statements relating to not
providing packet formats for ANY of the valid T.38 = transport protocols.
Since we = are in agreement that this registration is not a candidate = for
consideration of packet = formats as requested in Section 5.14 of = RFC4566,
do I completely = remove the innocuous item (#7 in Section 3 = of
draft-salgueiro-mmusic-image-iana-registration-03) stating = that packet
formats are not = provided in this draft because it is instead = delegated
to T.38? Or is it = viewed as useful statement that adds clarity = and
should remain in the = draft?

I personally = don't have a preference either way.

I suggest = removing it. Section 5.14 of RFC4566 only mandates that packet formats = be documented for 'media types' (really 'media formats'), not top-level = media content types, and only for media formats that operate over raw = UDP.

OK. I can certainly live with removing it = since we are in violent agreement that it is not required to be there = based on 5.14.

The packet = format description for 'image' over 'udptl' using the 't38' media format = is properly delegated to the document that defines the 'udptl' protocol, = which is the T.38 recommendation itself, so it appears that this is all = consistent.



Interestingly, IANA has 'udptl' = listed in the SDP parameters = registry
for 'proto', with the Reference = being T.38... but RFC 4566 states = that
protocol registrations must refer to RFCs that describe = the protocol,
not documents from other SDOs = :-)

Yikes, that isn't good. In this case a pointer to T.38 is = the right
thing IMO, so I = think this is something that can easily be amended = in
4566bis. Copying Ali for = awareness.

Thanks.

I have a number of = editorial changes I'd like to propose; would you prefer those be sent in = some sort of 'diff' form as an email? If so, it would probably be = easiest if you sent me the XML source and I sent you back a diff to = that, and then you can decide whether to accept the changes or = not.

I have sent along the XML = separately to you to do with it as you see = fit.

Regards,

Gonzalo

Regards,

Gonzalo


Regards,

Gonzalo

On May = 20, 2011, at 12:51 AM, Yasubumi CHIMURA = wrote:

Hi = Miguel,

Thank you for your support about = Draft of "image" for T.38 = SDP.
I agree your = opinion.

Best = Regards,

Yasu = Chimura
-----Original = Message-----
From: Miguel A. Garcia = [mailto:Miguel.A.Garcia@ericsson.com]
Sent: = Thursday, May 19, 2011 4:30 = PM
To: Yasubumi = CHIMURA
Cc: 'DRAGE, Keith (Keith)'; = 'mmusic'; 'Flemming Andreasen'; = 'Noriyuki
SATO';
'OKUMURA Shinji'; Gonzalo = Salgueiro
Subject: Re: [MMUSIC] Process = for
draft-salgueiro-mmusic-image-iana-registration

Hi = Yasu,

My opinions, as an individual, = below.

On 18/05/2011 13:54, Yasubumi = CHIMURA = wrote:
Hi = Miguel,

I'm = Chimura from OKI-J and = CIAJ.
=

I have = one comment = about
=
draft-salgueiro-mmusic-image-iana-registration.

RFC4566 = described the procedure = following;
RFC4566 = p24
The = media type registration SHOULD define the = packet
format = for use with UDP = transport.
...
<= /blockquote>
For media using other transport = protocols, the<fmt> field = is
protocol= specific. Rules for interpretation of the<fmt> = sub-
<= blockquote type=3D"cite">
field = MUST be defined when registering new protocols (see = Section
8.2.2).

Therefore, if it use without UDP transport in m=3Dimage, = should = be
describe
the packet = format.

And, = if it use with UDP transport in m=3Dimage, should be describe = the
definition of fmt and the attribution(a=3D) of = SDP.
<= blockquote type=3D"cite">

I get the point, I belive. But I = doubt we can just define a = single
packet
format for sending any type of = "image" media types. I guess = we
should = say
that T38 is one of the possible = packet formats, and the full = packet
format description when using = UDP transport is described in ITU-T = T.38
recommendation. If in the = future, there are additional formats = of
"image"
with UDP, then a different = specification should describe the = packet
format.

Also, notice that T38 allows = several transport protocols, including = TCP,
UDP, UDPTL, = RTP.

My suggestion is that the = registration of the media type = "image"
delegates the packet format = description over UDP to the media = format
description. Also, the draft = should say that, when T38 is the = media
format, ITU-T T.38 contains the = packet format = description.

BR,
<= blockquote type=3D"cite">

Miguel

Best = Regards,

Yasu = Chimura
-----Original = Message-----
From: = Miguel A. Garcia = [mailto:Miguel.A.Garcia@ericsson.com]
Sent: Tuesday, May 10, 2011 2:51 = PM
To: = DRAGE, Keith = (Keith)
Cc: = mmusic; Flemming Andreasen; 'Yasubumi = CHIMURA'
Subject:= Re: [MMUSIC] Process = for
draft-salgueiro-mmusic-image-iana-registration

Hi = Keith,

An = individual document will not go through an official WGLC, but = I
guess
the working group can always get = a closer look at it before the = author
submitting it as an individual = submission.

/Miguel

On = 09/05/2011 17:50, DRAGE, Keith (Keith) = wrote:
If you are going to WGLC this = document, surely you might as well = make
<= /blockquote>
this
=
a = working group = draft.

If it = is AD sponsored, then the first question is sufficient - = look
<= /blockquote>
at = it
now, = and then it goes for a four week IETF last = call.
=

Keith

-----Original = Message-----
From: mmusic-bounces@ietf.org = <mailto:mmusic-bounces@ietf.org= >
<= /blockquote>
<mailto:mmusic-bounces@ietf.org= >
<= /blockquote>
[mailto:mmusic-bounces@ietf.org] = On = Behalf
Of Miguel A. = Garcia
Sent: 09 May 2011 = 08:04
=
To: = mmusic
Cc: Flemming Andreasen; = 'Yasubumi = CHIMURA'
Subject: [MMUSIC] Process for = draft-salgueiro-mmusic-image-iana-
registration

In relation with the = registration of the SDP 'image' media = type,
=
we = are
going to try to expedite this = draft, since it is a very = simple
missing
registration.

The idea is to progress the = draft as an individual = submission,
AD-sponsored draft. So, the = chairs would like the working = group
=
to = take
<= /blockquote>
a
closer = look at it (it is a short one), so that we can go to WGLC in = a
short time = frame.

So please, send comments as soon = as possible. Do not wait to = the
WGLC.

BR,
<= /blockquote>

Miguel
--
Miguel A. = Garcia
+34-91-339-3608
Ericsson= = Spain
=
_______________________________________________
mmusic = mailing = list
<= /blockquote>
mmusic@ietf.org <mailto:mmusic@ietf.org> <mailto:mmusic@ietf.org>
https://www.ietf.org= /mailman/listinfo/mmusic


--
Miguel A. = Garcia
+34-91-339-3608
Ericsson = Spain



_______________________________________________
mmusic mailing = list
mmusic@ietf.org <mailto:mmusic@ietf.org>
https://www.ietf.org= /mailman/listinfo/mmusic


--
Kevin P. = Fleming
Digium, Inc. | Director of Software = Technologies
Jabber: kfleming@digium.com <mailto:kfleming@digium.com> | = SIP:
kpfleming@digium.com <mailto:kpfleming@digium.com> = | Skype: kpfleming
445 Jan Davis Drive NW - = Huntsville, AL 35806 - USA
Check us out at www.digium.com <http://www.digium.com> = &
www.asterisk.org = <http://www.asterisk.org>
_______________________________________________
mmusic mailing = list
mmusic@ietf.org = <mailto:mmusic@ietf.org>
https://www.ietf.org= /mailman/listinfo/mmusic



--
Kevin P. = Fleming
Digium, Inc. | Director of Software Technologies
Jabber: = kfleming@digium.com | SIP: kpfleming@digium.com | Skype: = kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - = USA
Check us out at www.digium.com & www.asterisk.org

= --Apple-Mail-72--610432371-- From miguel.a.garcia@ericsson.com Wed May 25 01:15:41 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3B7E06D5 for ; Wed, 25 May 2011 01:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm7tT4qpy06O for ; Wed, 25 May 2011 01:15:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7D836E0664 for ; Wed, 25 May 2011 01:15:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b1-4ddcbaa7e657 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8A.89.20773.7AABCDD4; Wed, 25 May 2011 10:15:35 +0200 (CEST) Received: from [159.107.24.158] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 25 May 2011 10:15:35 +0200 Message-ID: <4DDCBAA6.80404@ericsson.com> Date: Wed, 25 May 2011 10:15:34 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Gonzalo Salgueiro Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mmusic Subject: [MMUSIC] Comments to draft-salgueiro-mmusic-image-iana-registration-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 08:15:41 -0000 Some comments, as an individual, to the 'image' IANA registration draft. They are mostly editorial. - The SDP example in Section 2 contains only relevant lines. I think it is not a big overhead to write all the SDP lines, including the v=, o=, s=, and t= lines. I prefer to see complete and syntactically correct SDP examples. - Consider the last two paragraphs in Section 2, i.e., those starting with: "This document complies with ...." and "The purpose of this document is ..." I believe the order of these paragraphs should be interchanged, so that the purpose of the document is first described, and then, once we know what the document is about to do, we learn whether it complies with the requirements in RFC 4566 for that matter. - Section 3, 5th bullet point. The text reads: (5) Purpose of the registered name: The currently registered list of SDP media types ('audio', 'video', 'text', 'application', and 'message') does not include one suitable for real-time facsimile (fax) applications. The 'image' media type for the Session Description Protocol (SDP) is primarily intended to be utilized as a parameter by SDP [RFC4566] in SIP [RFC3261] to establish T.38 [T38] media streams. I believe you should describe here the purpose of the "image" media type in SDP, not the purpose of the registration of the "image" media type, which is what is written. So, I would suggest a paragraph along these lines (feel free to amend them): The "image" media type describes a media stream that represents a still image. The submedia type further describes the format of the image. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ari.keranen@nomadiclab.com Wed May 25 04:04:13 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A3CE0690 for ; Wed, 25 May 2011 04:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkdVsJbDjMvB for ; Wed, 25 May 2011 04:04:12 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 595CAE0681 for ; Wed, 25 May 2011 04:04:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 8BA024E6E1; Wed, 25 May 2011 14:04:08 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z3Thf6PEnAC; Wed, 25 May 2011 14:04:07 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 8EBB24E6D8; Wed, 25 May 2011 14:04:07 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: <002901cc1976$d8b86420$8a292c60$@com> Date: Wed, 25 May 2011 14:04:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <002901cc1976$d8b86420$8a292c60$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: 'mmusic WG' Subject: Re: [MMUSIC] ICE TCP and TCP amplification attack (mitigation) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:04:13 -0000 On May 23, 2011, at 9:25 PM, Dan Wing wrote: >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Ari Keranen >> Sent: Thursday, May 19, 2011 7:29 AM >> To: mmusic WG >> Subject: [MMUSIC] ICE TCP and TCP amplification attack (mitigation) >>=20 >> Hi all, >>=20 >> Flemming identified a possible TCP amplification attack in ICE TCP: >>=20 >> On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote: >>> - Section 12 >>> I believe there is a TCP amplification attack similar to the STUN >> amplification attack that requires consideration, since the TCP >> connection is established prior to any STUN/ICE checks and involves = TCP >> state creation on the part of the attacked party. >>=20 >> That is, an attacker could put in the SDP offer a set of passive >> reflexive candidates with the address of the victim and the answerer >> would make a bunch of TCP connections towards the victim. >=20 > That attack is inherent to ICE itself, and not the fault or cause of > the TURN-TCP specification. If text is added to TURN-TCP, it would > be nice to couch it with something like: >=20 > A STUN amplification attack is described in Section 18.5.2 of=20 > [RFC5245], but unfortunately that specification did not describe > how [RFC5245] can also be used to launch a TCP amplification > attack. =20 >=20 > and the describe how TURN-TCP is but one way the TCP amplification > could be launched. The other way is that RFC5245 could be used > without TURN-TCP. I guess this is not really problem with TURN-TCP, but rather with ICE = TCP, whether you use TURN or not. But you're right, the basic = amplification attack is inherent to ICE itself. TCP just makes it worse = since the victim needs to create TCP connection state instead of just = dropping unsolicited UDP packets. Maybe we could say something along the = lines of: A STUN amplification attack is described in Section 18.5.2 of = [RFC5245]. Same considerations apply to TCP, but the amplification = effect with TCP is larger due to need for establishing a TCP connection = before any checks are performed. Therefore, an ICE agent SHOULD NOT have = more than X outstanding TCP connection attempts with the same peer to = the same IP address. Regarding this attack, we could also add to the end of section 7.1 (STUN = Client Procedures) in ICE TCP something like: [once the connection is established] if the peer's response to the = connectivity check is something else than a STUN message, the agent MUST = close the connection and consider all pairs with that remote candidate = as failed. (since apparently the remote candidate was not an ICE agent, but could = be a victim of a DoS attack) >> A possible mitigation, as Flemming suggested, would be to limit the >> number of outstanding TCP connection attempts to the same IP-address. >> That sounds reasonable to me, since having many (un-frozen) = candidates >> from the same IP address seem unlikely anyway, but are there any = other >> ideas? >=20 > That sounds like a good approach. =20 OK, then we'd need a recommended number; how many outstanding attempts = to the same IP address do we allow? Technically, one should be enough for all "normal" cases (right?), but = maybe, e.g., more than one interface may in fact be behind the same CGN = so more could be useful in some scenarios. How about 5? That should be = enough for even more exotic cases, but yet make any DoS attack pretty = weak. > I wonder if Errata should be raised against RFC5245, instead or in > addition? Do you mean that RFC5245 should also mention the added effect of TCP? Anyhow, probably also 5245(bis) could limit the number of outstanding = checks to the same IP address even if UDP is used and consider non-STUN = responses as a sign of invalid candidate, as discussed above. Cheers, Ari= From john.elwell@siemens-enterprise.com Wed May 25 08:13:11 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A62EE06BA for ; Wed, 25 May 2011 08:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qcgU2wsJyTI for ; Wed, 25 May 2011 08:13:09 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id C0B2FE0750 for ; Wed, 25 May 2011 08:13:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1306336387!14638007!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 17708 invoked from network); 25 May 2011 15:13:07 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-15.tower-174.messagelabs.com with SMTP; 25 May 2011 15:13:07 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id A32FE23F03E8 for ; Wed, 25 May 2011 17:13:07 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 25 May 2011 17:13:07 +0200 From: "Elwell, John" To: mmusic Date: Wed, 25 May 2011 17:13:06 +0200 Thread-Topic: Revised ice-updated-offer draft Thread-Index: Acwa7j+1tLPewP+cRFGXOIbZmer2LQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] Revised ice-updated-offer draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:13:11 -0000 Version 01 has been posted: https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updated-offer/ Compared with 00, this attempts to reflect the discussions in Prague, inclu= ding: - avoidance of the term "middlebox"; - discussion of 100rel and pre-conditions as possible solution to fax probl= em; - noted that the 3PCC issue exists anyway without ICE, but is more likely t= o arise with ICE; - new section 4 on whether we really need the updated offer; - revised conclusion section, suggesting relaxing the requirement for the I= CE updated offer. Comments welcome. John From dwing@cisco.com Wed May 25 09:02:56 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB804E0755 for ; Wed, 25 May 2011 09:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.481 X-Spam-Level: X-Spam-Status: No, score=-110.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M7hheTo8QB5 for ; Wed, 25 May 2011 09:02:56 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2C390E0718 for ; Wed, 25 May 2011 09:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4590; q=dns/txt; s=iport; t=1306339376; x=1307548976; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=ujeudhTwRjTY1T3Vm4CGiaULo6im58qU7ui0eUYyMK0=; b=kBeDT2E0fbMe15QnOe3QjoGxL1Vdkqg2M0gD6DbN49JGe6Zshq2hQrii /LbPS51dVbeqjQP7h4TtxrGjqYAB7NkduGHoyJyHC+bwWcOLsiLnrC0w4 ZqztWhQQH2xBz+vWbVuvQhtX4kgbs8iGOarHSC8jvXBBSKZgt8n+CCpcI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBAKEn3U2rRDoG/2dsb2JhbACXZ4FkjGF4iHCefZ13hhwEhluYew X-IronPort-AV: E=Sophos;i="4.65,267,1304294400"; d="scan'208";a="703206117" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 25 May 2011 16:02:55 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4PG2tC0003344; Wed, 25 May 2011 16:02:55 GMT From: "Dan Wing" To: "'Ari Keranen'" References: <002901cc1976$d8b86420$8a292c60$@com> In-Reply-To: Date: Wed, 25 May 2011 09:02:55 -0700 Message-ID: <099101cc1af5$35bd2640$a13772c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acway31Q1aVAHMKRRgy3zoIegb+6kgAKT/fA Content-Language: en-us Cc: 'mmusic WG' Subject: Re: [MMUSIC] ICE TCP and TCP amplification attack (mitigation) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 16:02:56 -0000 > -----Original Message----- > From: Ari Keranen [mailto:ari.keranen@nomadiclab.com] > Sent: Wednesday, May 25, 2011 4:04 AM > To: Dan Wing > Cc: 'mmusic WG' > Subject: Re: [MMUSIC] ICE TCP and TCP amplification attack (mitigation) > > On May 23, 2011, at 9:25 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >> Behalf Of Ari Keranen > >> Sent: Thursday, May 19, 2011 7:29 AM > >> To: mmusic WG > >> Subject: [MMUSIC] ICE TCP and TCP amplification attack (mitigation) > >> > >> Hi all, > >> > >> Flemming identified a possible TCP amplification attack in ICE TCP: > >> > >> On May 10, 2011, at 5:06 AM, Flemming Andreasen wrote: > >>> - Section 12 > >>> I believe there is a TCP amplification attack similar to the STUN > >> amplification attack that requires consideration, since the TCP > >> connection is established prior to any STUN/ICE checks and involves > TCP > >> state creation on the part of the attacked party. > >> > >> That is, an attacker could put in the SDP offer a set of passive > >> reflexive candidates with the address of the victim and the answerer > >> would make a bunch of TCP connections towards the victim. > > > > That attack is inherent to ICE itself, and not the fault or cause of > > the TURN-TCP specification. If text is added to TURN-TCP, it would > > be nice to couch it with something like: > > > > A STUN amplification attack is described in Section 18.5.2 of > > [RFC5245], but unfortunately that specification did not describe > > how [RFC5245] can also be used to launch a TCP amplification > > attack. > > > > and the describe how TURN-TCP is but one way the TCP amplification > > could be launched. The other way is that RFC5245 could be used > > without TURN-TCP. > > I guess this is not really problem with TURN-TCP, but rather with ICE > TCP, whether you use TURN or not. But you're right, the basic > amplification attack is inherent to ICE itself. TCP just makes it worse > since the victim needs to create TCP connection state instead of just > dropping unsolicited UDP packets. Maybe we could say something along > the lines of: > > A STUN amplification attack is described in Section 18.5.2 of > [RFC5245]. Same considerations apply to TCP, but the amplification > effect with TCP is larger due to need for establishing a TCP connection > before any checks are performed. Therefore, an ICE agent SHOULD NOT > have more than X outstanding TCP connection attempts with the same peer > to the same IP address. Such a statement seems out of scope for TURN-TCP, but it's the best we can do without updating ICE itself to mention the TCP attack, I guess. > Regarding this attack, we could also add to the end of section 7.1 > (STUN Client Procedures) in ICE TCP something like: > > [once the connection is established] if the peer's response to the > connectivity check is something else than a STUN message, the agent ..................................^^^^ "other" > MUST close the connection and consider all pairs with that remote > candidate as failed. > > (since apparently the remote candidate was not an ICE agent, but could > be a victim of a DoS attack) Ok. > >> A possible mitigation, as Flemming suggested, would be to limit the > >> number of outstanding TCP connection attempts to the same IP- > address. > >> That sounds reasonable to me, since having many (un-frozen) > candidates > >> from the same IP address seem unlikely anyway, but are there any > other > >> ideas? > > > > That sounds like a good approach. > > OK, then we'd need a recommended number; how many outstanding attempts > to the same IP address do we allow? > > Technically, one should be enough for all "normal" cases (right?), but > maybe, e.g., more than one interface may in fact be behind the same CGN > so more could be useful in some scenarios. How about 5? That should be > enough for even more exotic cases, but yet make any DoS attack pretty > weak. 5 sounds plenty. > > I wonder if Errata should be raised against RFC5245, instead or in > > addition? > > Do you mean that RFC5245 should also mention the added effect of TCP? Yes. > Anyhow, probably also 5245(bis) could limit the number of outstanding > checks to the same IP address even if UDP is used and consider non-STUN > responses as a sign of invalid candidate, as discussed above. Yes, that is also a good idea. -d > > > Cheers, > Ari= From gsalguei@cisco.com Wed May 25 16:50:40 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F288E07F1 for ; Wed, 25 May 2011 16:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k50e4KS1V7N1 for ; Wed, 25 May 2011 16:50:39 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id B2795E07C5 for ; Wed, 25 May 2011 16:50:39 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4PNobRc004743; Wed, 25 May 2011 19:50:37 -0400 (EDT) Received: from rtp-gsalguei-8716.cisco.com (rtp-gsalguei-8716.cisco.com [10.116.61.55]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p4PNoXdh001911; Wed, 25 May 2011 19:50:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-115--504765101 From: Gonzalo Salgueiro In-Reply-To: <4DDCBAA6.80404@ericsson.com> Date: Wed, 25 May 2011 19:50:32 -0400 Message-Id: <74A37471-6554-44FD-B186-57398D9D9691@cisco.com> References: <4DDCBAA6.80404@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1084) Cc: mmusic Subject: Re: [MMUSIC] Comments to draft-salgueiro-mmusic-image-iana-registration-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 23:50:40 -0000 --Apple-Mail-115--504765101 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the review Miguel. The suggested edits all seemed reasonable = to me. I have addressed them all in the latest version = (http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-registration= ). Please let me know if there is any remaining feedback. Regards, Gonzalo On May 25, 2011, at 4:15 AM, Miguel A. Garcia wrote: > Some comments, as an individual, to the 'image' IANA registration = draft. They are mostly editorial. >=20 > - The SDP example in Section 2 contains only relevant lines. I think = it is not a big overhead to write all the SDP lines, including the v=3D, = o=3D, s=3D, and t=3D lines. I prefer to see complete and syntactically = correct SDP examples. >=20 > - Consider the last two paragraphs in Section 2, i.e., those starting = with: >=20 > "This document complies with ...." >=20 > and >=20 > "The purpose of this document is ..." >=20 > I believe the order of these paragraphs should be interchanged, so = that the purpose of the document is first described, and then, once we = know what the document is about to do, we learn whether it complies with = the requirements in RFC 4566 for that matter. >=20 > - Section 3, 5th bullet point. The text reads: >=20 > (5) Purpose of the registered name: >=20 > The currently registered list of SDP media types ('audio', > 'video', 'text', 'application', and 'message') does not > include one suitable for real-time facsimile (fax) > applications. The 'image' media type for the Session > Description Protocol (SDP) is primarily intended to be > utilized as a parameter by SDP [RFC4566] in SIP [RFC3261] to > establish T.38 [T38] media streams. >=20 > I believe you should describe here the purpose of the "image" media = type in SDP, not the purpose of the registration of the "image" media = type, which is what is written. So, I would suggest a paragraph along = these lines (feel free to amend them): >=20 > The "image" media type describes a media stream that represents a = still image. The submedia type further describes the format of the = image. >=20 >=20 >=20 > /Miguel >=20 >=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain --Apple-Mail-115--504765101 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://tools.ietf.org/html/draft-salgueiro-mmusic-image-iana-regi= stration).

Please let me know if there is any = remaining = feedback.

Regards,

Gonza= lo

On May 25, 2011, at 4:15 AM, Miguel A. = Garcia wrote:

Some comments, as an individual, to the 'image' IANA = registration draft. They are mostly editorial.

- The SDP example = in Section 2 contains only relevant lines. I think it is not a big = overhead to write all the SDP lines, including the v=3D, o=3D, s=3D, and = t=3D lines. I prefer to see complete and syntactically correct SDP = examples.

- Consider the last two paragraphs in Section 2, i.e., = those starting with:

"This document complies with ...."

= and

"The purpose of this document is ..."

I believe the = order of these paragraphs should be interchanged, so that the purpose of = the document is first described, and then, once we know what the = document is about to do, we learn whether it complies with the = requirements in RFC 4566 for that matter.

- Section 3, 5th bullet = point. The text reads:

  (5)  Purpose of the = registered name:

=           The = currently registered list of SDP media types ('audio',
=           'video', = 'text', 'application', and 'message') does not
=           include one = suitable for real-time facsimile (fax)
=           applications. =  The 'image' media type for the Session
=           Description = Protocol (SDP) is primarily intended to be
=           utilized as = a parameter by SDP [RFC4566] in SIP [RFC3261] to
=           establish = T.38 [T38] media streams.

I believe you should describe here the = purpose of the "image" media type in SDP, not the purpose of the = registration of the "image" media type, which is what is written. So, I = would suggest a paragraph along these lines (feel free to amend = them):

  The "image" media type describes a media = stream that represents a still image. The submedia type further = describes the format of the = image.



/Miguel



--
Miguel A. = Garcia
+34-91-339-3608
Ericsson = Spain

= --Apple-Mail-115--504765101-- From Bert.Greevenbosch@huawei.com Wed May 25 19:41:44 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C892DE0722 for ; Wed, 25 May 2011 19:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgEom-9C1dBB for ; Wed, 25 May 2011 19:41:44 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 31220E06A3 for ; Wed, 25 May 2011 19:41:44 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS00JV47FJ8L@szxga03-in.huawei.com> for mmusic@ietf.org; Thu, 26 May 2011 10:40:31 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLS003CF7FISV@szxga03-in.huawei.com> for mmusic@ietf.org; Thu, 26 May 2011 10:40:31 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 26 May 2011 10:40:22 +0800 Received: from SZXEML501-MBX.china.huawei.com ([169.254.5.158]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Thu, 26 May 2011 10:40:30 +0800 Date: Thu, 26 May 2011 02:40:30 +0000 From: Bert Greevenbosch X-Originating-IP: [10.70.109.52] To: "mmusic@ietf.org" Message-id: <46A1DF3F04371240B504290A071B4DB6012DA422@szxeml501-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_djyl4ViV1e2dnFOfRgt03w)" Content-language: en-US Accept-Language: en-GB, zh-CN, en-US Thread-topic: Upload of draft-greevenbosch-parallax-attribute-01 and draft-greevenbosch-signal-3d-format-01 Thread-index: AcwbTkcND9jPBoDHQs+7B8PIM6Rm9Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [MMUSIC] Upload of draft-greevenbosch-parallax-attribute-01 and draft-greevenbosch-signal-3d-format-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 02:41:44 -0000 --Boundary_(ID_djyl4ViV1e2dnFOfRgt03w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, Following the discussions on the mailing list, I have uploaded new versions of the 3D drafts: http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-parallax-attribute/ The main change is normalisation of the unit to a screen width of 11520 pixels. http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/ Sections 7 and 8 have been added. Section 7 addresses the SDP offer/answer model for compliant devices, whereas section 8 addresses backwards compatibility with legacy devices. I would like to thank all that have provided comments to the previous version, they have been very helpful for creating the new version of the draft. I look forward to comments to the new version too! Best regards, Bert --Boundary_(ID_djyl4ViV1e2dnFOfRgt03w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

Following the discussions on the mailing list, I have uploaded new versions of the 3D drafts:

 

http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-parallax-attribute/

The main change is normalisation of the unit to a screen width of 11520 pixels.

 

http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-signal-3d-format/

Sections 7 and 8 have been added. Section 7 addresses the SDP offer/answer model for compliant devices, whereas section 8 addresses backwards compatibility with legacy devices.

 

I would like to thank all that have provided comments to the previous version, they have been very helpful for creating the new version of the draft.

 

I look forward to comments to the new version too!

 

Best regards,

Bert

--Boundary_(ID_djyl4ViV1e2dnFOfRgt03w)-- From Martin.Stiemerling@neclab.eu Thu May 26 03:35:39 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31957E06B6 for ; Thu, 26 May 2011 03:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.398 X-Spam-Level: X-Spam-Status: No, score=-98.398 tagged_above=-999 required=5 tests=[AWL=-3.291, BAYES_50=0.001, CN_BODY_35=0.339, HELO_EQ_DE=0.35, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k0BoEohb516 for ; Thu, 26 May 2011 03:35:38 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 63AC3E068F for ; Thu, 26 May 2011 03:35:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B615F2800034E; Thu, 26 May 2011 12:35:37 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sb3JFH47sT6o; Thu, 26 May 2011 12:35:37 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 92F9728000191; Thu, 26 May 2011 12:35:22 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.225]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Thu, 26 May 2011 12:35:22 +0200 From: Martin Stiemerling To: "Roy Yue(PeiYu)" , "mmusic@ietf.org" Thread-Topic: Review Report of RTSP 2.0 draft Thread-Index: AcwZ6O+T9jCll7vaQYC1JLTWCU/oVQBp5Yqg Date: Thu, 26 May 2011 10:35:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.207] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Flemming Andreasen Subject: Re: [MMUSIC] Review Report of RTSP 2.0 draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 10:35:39 -0000 RGVhciBSb3ksDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXchDQoNCkkgd2lsbCBnbyB0aHJvdWdo IHlvdXIgY29tbWVudHMgc29vbi4NCg0KICBNYXJ0aW4NCg0KbWFydGluLnN0aWVtZXJsaW5nQG5l Y2xhYi5ldQ0KDQpORUMgTGFib3JhdG9yaWVzIEV1cm9wZSAtIE5ldHdvcmsgUmVzZWFyY2ggRGl2 aXNpb24NCk5FQyBFdXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2Us IDEgVmljdG9yaWEgUm9hZCwgTG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAy ODMyMDE0IA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbW11c2lj LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4g QmVoYWxmIE9mIFJveSBZdWUoUGVpWXUpDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAyNCwgMjAxMSAx MDowMyBBTQ0KPiBUbzogbW11c2ljQGlldGYub3JnDQo+IENjOiBGbGVtbWluZyBBbmRyZWFzZW4N Cj4gU3ViamVjdDogW01NVVNJQ10gUmV2aWV3IFJlcG9ydCBvZiBSVFNQIDIuMCBkcmFmdA0KPiAN Cj4gSGVsbG8gTWlndWVsLCBGbGVtbWluZywgZXQgYWwsDQo+IA0KPiANCj4gDQo+IEFzIHByb21p c2VkIGR1cmluZyBJRVRGICM4MCwgSSBoYXZlIGZpbmlzaGVkIHJldmlld2luZyB0aGUgd2hvbGUg UlRTUA0KPiAyLjAgZHJhZnQgKGkuZS4gZHJhZnQtaWV0Zi1tbXVzaWMtcmZjMjMyNmJpcy0yNyku DQo+IA0KPiBFbmNsb3NlZCBpcyB0aGUgY29tbWVudCBhbmQgZWRpdG9yaWFsIHByb3Bvc2FsIEkg aGF2ZSwgaW4gYSBzaW1wbGUNCj4gZXhjZWwgc2hlZXQuDQo+IA0KPiBQUzogc2hvdWxkIEkgcHV0 IGl0IGluIGFueSBzcGVjaWZpYyBmb3JtYXQgaW5zdGVhZD8NCj4gDQo+IA0KPiANCj4gQW1vbmcg dGhlIGNvbW1lbnRzLCB0eXBvcywgYnVncywgdGhlIGZpcnN0IDE0IGNvbW1lbnRzIGFyZSBtb3Jl DQo+IHNpZ25pZmljYW50LCB3aGlsZSBvdGhlcnMgYXJlIG1vcmUgb2J2aW91cy4NCj4gDQo+IA0K PiANCj4gQmVzdCByZWdhcmRzLA0KPiANCj4gUm95KMDWxeDT8SkNCj4gSHVhd2VpIFNvZnR3YXJl IFRlY2hub2xvZ2llcyBDby4sIEx0ZCBodWF3ZWlfbG9nbw0KPiANCj4gDQo+IE41LCBOTy4gMTAx LCBIdWF3ZWkgQmFzZQ0KPiBSdWFuamlhbiBBdiwgWXVIdWEgRGlzdA0KPiBOYW5qaW5nLCAyMTAw MTIsIFAuUi5DDQo+IFRlbDogKzg2LTI1LTU2NjIyMDU4DQo+IEZheDogKzg2LTI1LTU2NjI0MDgx DQo+IE1vYmlsZTogKzg2LTEzODA5MDMwNDAxDQo+IEVtYWlsOiB5dWVwZWl5dUBodWF3ZWkuY29t DQo+IGh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiCx vtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6KjrL32z97T2reiy824+MnPw+a12Na3 1tDB0LP2tcS49sjLu/LIutfpoaO9+w0KPiDWucjOus7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzA qLWrsrvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTWxqGiu/LJoreio6mxvtPKvP7W0A0KPiC1xNDF z6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7Iy7Kiyb6z /bG+08q8/qOhDQo+IFRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25m aWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbQ0KPiBIVUFXRUksIHdoaWNoDQo+IGlzIGludGVuZGVk IG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkDQo+ IGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlu IGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLA0KPiB0b3RhbCBvciBwYXJ0 aWFsDQo+IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVy c29ucyBvdGhlciB0aGFuIHRoZQ0KPiBpbnRlbmRlZA0KPiByZWNpcGllbnQocykgaXMgcHJvaGli aXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZQ0KPiBub3Rp ZnkgdGhlIHNlbmRlciBieQ0KPiBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRl IGl0IQ0KDQo= From iesg-secretary@ietf.org Tue May 31 10:39:47 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134C3E07A2; Tue, 31 May 2011 10:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIDstL5qWXgJ; Tue, 31 May 2011 10:39:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A67E07B5; Tue, 31 May 2011 10:39:46 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110531173946.28367.24439.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2011 10:39:46 -0700 Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'IANA Registry for Interactive Connectivity Establishment (ICE) Options' to Proposed Standard (draft-ietf-mmusic-ice-options-registry-02.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:39:47 -0000 The IESG has approved the following document: - 'IANA Registry for Interactive Connectivity Establishment (ICE) Options' (draft-ietf-mmusic-ice-options-registry-02.txt) as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-options-registry/ Technical Summary: It has been identified that Interactive Connectivity Establishment (ICE) RFC5245 is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC5245. Working Group Summary The document was produced in a short period of time to rectify a missing IANA registry for ICE. The document is straightforward and represents the consensus of the MMUSIC WG. Document Quality The document quality is good. There are no known implementations of ice-options, however it is needed for "Explicit Congestion Notification (ECN) for RTP over UDP" (draft-ietf-avt-ecn-for-rtp) currently being developed in the AVTCORE WG. Personnel Flemming Andreasen is the document shepherd. Gonzalo Camarillo is the responsible AD. From wwwrun@rfc-editor.org Tue May 31 16:00:01 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507C3E0932; Tue, 31 May 2011 16:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.053 X-Spam-Level: X-Spam-Status: No, score=-102.053 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j1JCYba2tFf; Tue, 31 May 2011 16:00:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id E5069E0930; Tue, 31 May 2011 16:00:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5A842E0747; Tue, 31 May 2011 16:00:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110531230000.5A842E0747@rfc-editor.org> Date: Tue, 31 May 2011 16:00:00 -0700 (PDT) Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 6236 on Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 23:00:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6236 Title: Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) Author: I. Johansson, K. Jung Status: Standards Track Stream: IETF Date: May 2011 Mailbox: ingemar.s.johansson@ericsson.com, kyunghun.jung@samsung.com Pages: 23 Characters: rfc6236 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-image-attributes-11.txt URL: http://www.rfc-editor.org/rfc/rfc6236.txt This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a %low-end %hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. [STANDARDS-TRACK] This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From cris.pascual.gonzalez@gmail.com Tue May 31 18:10:12 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52ECE0795 for ; Tue, 31 May 2011 18:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4vIDlzLJTX3 for ; Tue, 31 May 2011 18:10:12 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id EEC9AE0763 for ; Tue, 31 May 2011 18:10:11 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p511AAW8026930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Jun 2011 03:10:10 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p511AAxN021558 for ; Wed, 1 Jun 2011 03:10:10 +0200 Received: from JLLORET (vpn245-13.vpns.upv.es [158.42.245.13]) by smtp.upv.es (8.13.6/8.13.6) with SMTP id p511A3cH003344 for ; Wed, 1 Jun 2011 03:10:07 +0200 Date: Wed, 1 Jun 2011 03:10:07 +0200 Message-Id: <201106010110.p511A3cH003344@smtp.upv.es> From: Cristina Pascual To: mmusic@ietf.org CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [MMUSIC] Last Mile, June 5th | CfP: VALID 2011 || October 23-28, 2011 - Barcelona, Spain X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 01:10:12 -0000 INVITATION: ================= Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. The submission deadline is June 5, 2011 In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== VALID 2011 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS VALID 2011: The Third International Conference on Advances in System Testing and Validation Lifecycle October 23-28, 2011 - Barcelona, Spain General page: http://www.iaria.org/conferences2011/VALID11.html Call for Papers: http://www.iaria.org/conferences2011/CfPVALID11.html - regular papers - short papers (work in progress) - posters Submission page: http://www.iaria.org/conferences2011/SubmitVALID11.html Submission deadline: June 5th, 2011 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the Editorial rules: http://www.iaria.org/editorialrules.html VALID 2011 Topics (topics and submission details: see CfP on the site) Robust design methodologies Designing methodologies for robust systems; Secure software techniques; Industrial real-time software; Defect avoidance; Cost models for robust systems; Design for testability; Design for reliability and variability; Design for adaptation and resilience; Design for fault-tolerance and fast recovery; Design for manufacturability, yield and reliability; Design for testability in the context of model-driven engineering Vulnerability discovery and resolution Vulnerability assessment; On-line error detection; Vulnerabilities in hardware security; Self-calibration; Alternative inspections; Non-intrusive vulnerability discovery methods; Embedded malware detection Defects and Debugging Debugging techniques; Component debug; System debug; Software debug; Hardware debug; System debug; Power-ground defects; Full-open defects in interconnecting lines; Physical defects in memories and microprocessors; Zero-defect principles Diagnosis Diagnosis techniques; Advances in silicon debug and diagnosis; Error diagnosis; History-based diagnosis; Multiple-defect diagnosis; Optical diagnostics; Testability and diagnosability; Diagnosis and testing in mo bile environments System and feature testing Test strategy for systems-in-package; Testing embedded systems; Testing high-speed systems; Testing delay and performance; Testing communication traffic and QoS/SLA metrics; Testing robustness; Software testing; Hardware testing; Supply-chain testing; Memory testing; Microprocessor testing; Mixed-signal production test; Testing multi-voltage domains; Interconnection and compatibility testing Testing techniques and mechanisms Fundamentals for digital and analog testing; Emerging testing methodologies; Engineering test coverage; Designing testing suites; Statistical testing; Functional testing; Parametric testing; Defect- and data-driven testing; Automated testing; Embedded testing; Autonomous self-testing; Low cost testing; Optimized testing; Testing systems and devices; Test standards Testing of wireless communications systems Testing of mobile wireless communication systems; Testing of wireless sensor networks; Testing of radio-frequency identification systems; Testing of ad-hoc networks; Testing methods for emerging standards; Hardware-based prototyping of wireless communication systems; Physical layer performance verification; On-chip testing of wireless communication systems; Modeling and simulation of wireless channels; Noise characterization and validation; Case studies and industrial applications of test instruments; Software verification and validation High-speed interface verification and fault-analysis; Software testing theory and practice; Model-based testing; Verification metrics; Service/application specific testing; Model checking; OO software testing; Testing embedded software; Quality assurance; Empirical studies for verification and validation; Software inspection techniques; Software testing tools; New approaches for software reliability verification and validation Testing and validation of run-time evolving systems Automated testing for run-time evolving systems; Testing and validation of evolving systems; Testing and validation of self-controlled systems; Testing compile-time versus run-time dependency for evolving systems; On-line validation and testing of evolving at run-time systems; Modeling for testability of evolving at run-time systems; Near real-time and real-time monitoring of run-time evolving systems; Verification and validation of reflective models for testing; Verification and validation of fault tolerance in run-time evolving systems Feature-oriented testing Testing user interfaces and user-driven features; Privacy testing; Ontology accuracy testing; Testing semantic matching; Testing certification processes; Testing authentication mechanisms; Testing biometrics methodologies and mechanisms; Testing cross-nation systems; Testing system interoperability; Testing system safety; Testing system robustness; Testing temporal constraints; Testing transaction-based properties; Directed energy test capabilities /microwave, laser, etc./; Testing delay and latency metrics Domain-oriented testing Testing autonomic and autonomous systems; Testing intrusion prevention systems; Firewall testing; Information assurance testing; Testing social network systems; Testing recommender systems; Testing biometric systems; Testing diagnostic systems; Testing on-line systems; Testing financial systems; Testing life threatening systems; Testing emergency systems; Testing sensor-based systems; Testing testing systems --------------------- VALID Advisory Chairs Andrea Baruzzo, Università degli Studi di Udine, Italy Cristina Seceleanu, Mälardalen University, Sweden Mehdi Tahoori, Karlsruhe Institute of Technology (KIT), Germany Mehmet Aksit, University of Twente - Enschede, The Netherlands VALID 2011 Research Institute Liaison Chairs Juho Perälä, VTT Technical Research Centre of Finland, Finland Alexander Klaus, Fraunhofer Institute for Experimental Software Engineering (IESE), Germany Kazumi Hatayama, Nara Institute of Science and Technology, Japan Alin Stefanescu, University of Pitesti, Romania Vladimir Rubanov, Institute for System Programming / Russian Academy of Sciences (ISPRAS), Russia Tanja Vos, Universidad Politécnica de Valencia, Spain VALID 2011 Industry Chairs Abel Marrero, Daimler Center for Automotive IT Innovations - Berlin, Germany Sebastian Wieczorek, SAP AG - Darmstadt, Germany Eric Verhulst, Altreonic, Belgium Committee: http://www.iaria.org/conferences2011/ComVALID11.html ==================== From cris.pascual.gonzalez@gmail.com Tue May 31 18:34:15 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413D7E07DE for ; Tue, 31 May 2011 18:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_20=-0.74, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQ7p1D2icZMY for ; Tue, 31 May 2011 18:34:15 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 83162E07D5 for ; Tue, 31 May 2011 18:34:14 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p511YDvO029998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Jun 2011 03:34:13 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p511YD6e027321 for ; Wed, 1 Jun 2011 03:34:13 +0200 Received: from JLLORET (vpn245-17.vpns.upv.es [158.42.245.17]) by smtp.upv.es (8.13.6/8.13.6) with SMTP id p511Y7Mg008816 for ; Wed, 1 Jun 2011 03:34:11 +0200 Date: Wed, 1 Jun 2011 03:34:11 +0200 Message-Id: <201106010134.p511Y7Mg008816@smtp.upv.es> From: Cristina Pascual To: mmusic@ietf.org CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [MMUSIC] Last Mile, June 5th | CfP: SIMUL 2011 || October 23-28, 2011 - Barcelona, Spain X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 01:34:15 -0000 INVITATION: ================= Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. The submission deadline is June 5, 2011. In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== SIMUL 2011 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS SIMUL 2011: The Third International Conference on Advances in System Simulation October 23-28, 2011 - Barcelona, Spain General page: http://www.iaria.org/conferences2011/SIMUL11.html Call for Papers: http://www.iaria.org/conferences2011/CfPSIMUL11.html - regular papers - short papers (work in progress) - posters Submission page: http://www.iaria.org/conferences2011/SubmitSIMUL11.html Submission deadline: June 5th, 2011 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the Editorial rules: http://www.iaria.org/editorialrules.html SIMUL 2011 Topics (topics and submission details: see CfP on the site) Simulation models Monte Carlo simulation; Statistical analysis of simulation output; Analytical simulation modeling; Discrete event simulation models; Credible simulation models; Multi-objective simulation models; Multisimulation with multiresolution, multistage multimodels; Verification and validation of simulation models; Simulation metamodels; Executable simulation models; Emulation models; Regression models and experimental designs; Kriging metamodeling; Kriging metamodeling in discrete-event simulation; Kriging modeling for global approximation Simulation methodologies Sensitivity analysis; Rare-event simulation methodology; Agent-based modeling and simulation; Regenerative steady-state simulation; Simulation-based ordinal optimization; Ontology-based simulation methodology; Simulation component reuse methodology; Two-level simulation methodology; Emulation methodologies; System adaptation simulation; Simulation methodologies for autonomic and autonomous systems; Virtual reality simulation methodologies; Virtualization simulation; Construction simulation methodologies Sensitivity analysis Systematic simulation using sensitive analysis; Probabilistic sensitivity analysis; Sensitivity analysis of simulation technologies (Monte Carlo, Streamline, Spatial models, etc.); Domain-oriented sensitivity analysis (optimization, estimation matching, climate); Sensitivity analysis of products features, formalisms, design optimization (systems, code); Assessing the competency of business services (public, health, transportation, etc.); Sensitivity analysis and performance extrapolation; Adjoint transient sensitivity analysis; Causality and sensitivity analysis; Assessing the accuracy of sensitivity analysis Simulation mechanisms Composing simulation models; Reusable simulation model; Uncertainty simulation; Continuous-variable simulation optimization; Approximate zero-variance simulation; Probabilistic processes for simulation; Progressive model fitting; Steady-state simulations with initial transients; Merging simulation and optimization; Simulation optimization, stochastic programming and robust optimization; Overlapping variance estimators; Kriging interpolation in simulation; Kriging versus regression analysis; Interpolation; Random simulation; Prediction and simulation; Interpolation /Kriging, Cokriging, Conditional Simulation, and Inverse Distance Weighting/ Model based system quality prediction Model based prediction of system quality characteristics and their trade-offs; Prediction models; Methods and tools for system quality prediction; Reliability prediction; Security prediction; Risk prediction; Performance prediction; Uncertainty handling in prediction models; Prediction of change impacts on system quality and risk; Quality and trustworthiness of prediction models; Predictability of system quality characteristics; Predictability of dynamic and adaptive systems; Data acquisition methods in system quality prediction; Traceability and maintainability of prediction models; Inference types in prediction models; Experience reports on and application areas for system quality prediction; Empirical studies on system quality prediction Distributed simulation Large-scale simulation experiments; Industrial scale simulation; Time aspects in distributed simulation; Resource constraints in distributed simulation; Distributed disaster decision simulation; Simulation for rapid assessment of distributed impacts; Parallel and distributed simulation Human-in simulation User-in-the-middle simulations; User-feedback in simulations; User-adaptive simulations; Bioterrorism preparedness simulation; Probabilistic risk assessment; Measurement of situation awareness Simulations in advanced environments Simulation in Virtualized systems; Simulation in Cloud environments; Simulations in GRID environments; Simulation in Cognitive systems; Simulation in P2P systems; Simulation in Data Centers; Simulation in Power Distribution Centers; Simulation in micro- and nano-systems; Simulation in Geospatial systems; Geostatistics simulation; Spatial simulation; Simulation in Self-Adaptable systems; Simulation in Ubiquitous systems; Simulation in Underwater Vehicular and Communications systems; Simulations in Mobile and Vehicular systems; Simulation in eHealth systems;Computational fluid dynamics simulations for urban and environmental applications Practical applications on process simulations Uncertainty in industrial practice; Simulation for business planning; Application to finance; Logistics simulation; Supply chain simulation; Software reliability simulation; Simulation in vehicular systems /avionics, satellites, terrestrial/; Simulation models for manufacturing; Climate and weather-related simulations; Biological system simulation; Chemical system simulation; Commercial simulation environments; Healthcare simulation; Hospital planning; Simulation-based scheduling; Simulation in warehouse operations; Manufacturing simulation interoperability; Telecommunications simulations /reliability, queuing, fault spreading, virus contamination/; Cyber-attack modeling and simulation; Sensor fusion simulation Case studies on social simulation Group-work interaction simulation; Behavior analysis in simulations; Social need simulations; Simulating urban open spaces; Social decision simulation; Real-time decision making simulation; e-Polling simulation; Validation of simulated real-world; Simulation to predict market behavior; Predictions via similarity-based data-mining; Simulation of groups in e-Government systems; Simulation of urban mobility Online social simulation Online social models, social networking; Simulation of conflicts, cooperation, persuasions; Simulation of dynamics, group decisions, emerging behavior and situations; Simulation of interactive games, predictions and distributed tasks; Simulation of 3D online communities, massive online multiplayers, virtual social communities; Life problems simulation (sociology, political science, economics, anthropology, geography, archeology and linguistics); Group innovation and consumption simulation; Applications, techniques, tools, computational frameworks, experiments and lessons Building simulation Simulation of building physics; Human simulation of the indoor environment; Civil-oriented and enterprise-oriented simulations; Simulation of building services (lightning, heating, cooling, ventilation, insulation, etc.); Simulation of energy capture and conversion; Simulation of solar buildings, geothermal energy buildings; Simulation for earthquakes, flooding, fire propagation, etc.; Simulation of design practice; Tools and applications to simulate building-related properties and situations Transport simulation Transport system models; Airport simulation; Public transport simulation; Merchandise port simulation; Rural transport simulation during harvest time; Shipping transport simulation; Content and volume-based transport simulation; Simulation of traffic control and synchronization; Prediction accuracy of transport simulations; Simulation of transport projects Warfare simulation Warfare simulation environments and models; Tactical and strategic warfare simulation; Attack warfare simulation; Urban warfare simulation; Warfare simulation in unknown environment; Underwater, terrestrial, and spatial simulations; Hierarchical control simulation; Warfare gaming Simulation tools and platforms Discrete-event simulation software; Commercial off-the-shelf simulation package interoperability; Ontology-based tools for simulation integration; Simulation frameworks for energy-efficient systems; Public system applications; Simulators for business planning; Simulation tools for systems biology; Simulation tools for constructions /bridges, railways, industrial buildings, subways/ Experience report on ready-to-use tools ShowFlow and XJ technologies; Rockwell Automation and Frontline Systems; SIMULE-Planner, AutoMOD; PMC-Kanban Simulator, Program Portfolio Simulator and Asprova Scheduler; 3D simulator tool-kits; Wolverine Software-SLX; OPNET; OMNET++; NIIST; NS-2; NS-3; ATDI ICS; Qualnet; Dymola; Matlab/Simulink; Open source tools ---------------------------- SIMUL Advisory Chairs Edward Williams, PMC-Dearborn, USA Paul Fishwick, University of Florida-Gainesville, USA Christoph Reinhart, Harvard University - Cambridge, USA SIMUL 2011 Research Liaison Chairs Tae-Eog Lee, KAIST, Korea Marko Jaakola, VTT Technical Research Centre of Finland, Finland SIMUL 2011 Industry Liaison Chairs Diglio A. Simoni, RTI International – RTP, USA Shengnan Wu, American Airlines, USA Ann Dunkin, Palo Alto Unified School District, USA Tejas R. Gandhi, Virtua Health-Marlton, USA SIMUL 2011 Special Area Chairs Model-based system prediction Georgiy Bobashev, RTI International -Research Triangle Park, USA Aida Omerovic, SINTEF & University of Oslo, Norway Process simulation Ian Flood, University of Florida, USA Gregor Papa, Jozef Stefan Institute - Ljubljana, Slovenia SIMUL 2011 Publicity Chairs Nuno Melao, Catholic University of Portugal - Viseu, Portugal Committee: http://www.iaria.org/conferences2011/ComSIMUL11.html ====================